HTTPS everywhere, no exceptions
Every website and app Marcus generates serves traffic over HTTPS by default. We provision TLS certificates automatically when you connect a custom domain, and the free preview domains use HTTPS from the first deploy. HTTP requests redirect to HTTPS—there's no setting to turn encryption off.
This protects data in transit between your visitors and the server. Search engines favour HTTPS sites, and browsers flag HTTP pages as "Not secure," so we make the secure choice the only choice.
Content Security Policy headers
Marcus-built sites send a Content Security Policy header with every response. The default policy blocks inline scripts, restricts resource origins, and prevents common cross-site scripting attacks. If you embed third-party widgets—analytics, chat tools, payment forms—Marcus adjusts the CSP directives automatically based on the components you use.
You can tighten the policy further in the project settings if your use case needs stricter controls. We log CSP violations in the dashboard so you can spot attempted attacks or misconfigured integrations.
Parameterised database queries
Any database interaction Marcus generates uses parameterised queries. User input never concatenates directly into SQL strings, which closes the door on SQL injection attacks. This applies to forms, search filters, user authentication, and any dynamic content your site pulls from the database.
If you write custom backend logic—Node.js functions, API endpoints—you're responsible for maintaining that same discipline. Marcus provides a query builder that enforces parameterisation, so stick with that instead of writing raw SQL unless you know exactly what you're doing.
Payment data stays with Stripe
Marcus integrates Stripe for payments on Builder and Studio plans. When a visitor enters card details, that data goes directly to Stripe's servers through their embedded checkout or Elements components. We never log, store, or process payment card numbers, CVV codes, or full account details.
Our database holds only the Stripe customer ID and transaction metadata—amounts, timestamps, invoice references. This means we're out of scope for most PCI-DSS obligations, and you inherit that same protection when you use Marcus for e-commerce.
Password hashing with bcrypt
If your project includes user accounts, Marcus hashes passwords with bcrypt before storing them. Bcrypt is a slow, adaptive hashing function designed to resist brute-force attacks. Each password gets a unique salt, so even identical passwords produce different hashes.
We never store plaintext passwords, and we can't retrieve the original password for a user—password reset flows generate time-limited tokens sent by email. If you export your project as a ZIP and self-host, the same bcrypt implementation travels with the code.
Audit log for project changes
Every action in the Marcus dashboard—deploys, setting changes, domain updates, user invitations—appears in the project audit log. The log records who made the change, when, and from which IP address. Studio plan projects keep 90 days of history; Builder plan keeps 30 days.
Audit logs help you trace configuration drift, investigate suspicious activity, and meet compliance requirements if your organisation needs an evidence trail. You can export the log as CSV for offline archiving.
EU data residency by default
Marcus hosts all infrastructure—application servers, databases, file storage—in EU data centres. Your site content, user data, backups, and logs stay within the European Union unless you explicitly configure a deployment region outside the EU (available on Studio plan only).
This simplifies GDPR compliance and avoids questions about US surveillance laws or data transfer agreements. Anthropic Claude, the AI model behind Marcus, processes prompts in US facilities, but we don't send your users' personal data or site content to the model—only your build instructions and design preferences.
What you still need to think about
Marcus secures the infrastructure and the code it writes, but two areas remain your responsibility. First, if you add custom code—JavaScript in the front end, server functions, third-party libraries—you own the security review for that code. Marcus can't audit logic it didn't generate. Avoid pulling in unmaintained npm packages, and don't paste code from forums without understanding it.
Second, user-generated content. If your site accepts comments, forum posts, file uploads, or profile bios, you need moderation and input validation appropriate to your risk tolerance. Marcus sanitises output to prevent stored XSS, but it won't judge whether a comment contains harassment or whether an uploaded PDF is malware. Configure file type restrictions, size limits, and consider a moderation queue for public-facing content.