HTTPS everywhere, no exceptions
Every website and app Marcus generates serves traffic over HTTPS by default. Hosted pages at aimarcus.love/p/ use HTTPS from the first build. 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.
Project isolation and owner checks
Each project's files live in their own directory on the server, and every file path is checked against that directory, so one project can never read another project's files.
Before Marcus rebuilds, exports, publishes or deletes a project, the server confirms the request comes from the project's owner. A request from any other account gets a 403 and changes nothing.
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.