The security baseline: twelve items, checked for the site in hand
Before Anticode publishes a site, it works out a security baseline for that particular site: twelve items in four groups, from HTTPS to backups. Most are met by how Anticode serves every site. A few depend on the site and its owner, and two only apply once the site collects people's data. Publishing waits while any item that applies is failing.
A baseline that depends on the site
Generic security checklists treat a one-page portfolio and a booking site holding customers' phone numbers the same. They shouldn't. A website security baseline is more useful when it asks what this site actually does: if it has no forms, there's no visitor data to protect behind an extra sign-in step; if it takes bookings, there is. Each item in Anticode's baseline says whether it applies, whether it passes, and what Anticode does for it, and where you can fix something, it says how.
The items
Encryption and perimeter
- HTTPS everywhere. Served only over TLS; plain-HTTP requests move permanently to HTTPS, and every address on the page uses HTTPS.
- HSTS. Every response tells browsers to use HTTPS for a year.
- Malicious requests filtered. Pages run no scripts, so injected script can't execute; form requests are checked for their origin, validated field by field and capped in size before anything is stored.
- DDoS mitigation and rate limiting. Served from Cloudflare's network; forms accept 8 sends per visitor every 10 minutes and 300 an hour per site.
Access control
- Two-factor sign-in for the owner and the publisher. Applies only when the site collects data. The account owner and the person publishing must sign in with an authenticator app code; other workspace members aren't checked.
- Least privilege. Each account sees only its own projects; in a shared workspace, members build and publish, owners and admins manage people and take sites down, and only the owner handles billing.
- Brute-force protection. Sign-in allows a limited number of tries per account and per address, and a two-factor sign-in ends after five wrong codes.
Application hardening
- Input validation and parameterised queries. Applies when the site collects data. Every visible field must have a type and a length limit in the page; submissions are validated again on the server, stored with bound queries and encrypted at rest.
- Security headers and CSP. A policy that blocks every script, frame and plugin, plus the other standard headers.
- Secure cookies. Published sites set no cookies; Anticode's own sign-in cookie is locked down.
Maintenance and recovery
- Automatic backups. Each publish keeps the previous version, ten in all.
- Malware scanning and integrity monitoring. Each file is rechecked against its fingerprint about once a day; see backups and integrity.
What "collects data" means
For a design-engine site, any form on any page counts: contact, booking, newsletter, an account request or a custom form. For an app, it's any use of anticode.send, the function app forms use to reach the owner. A site with none of these shows the two data items as doesn't apply, with the reason ("This site collects nothing, so there's no data to protect behind a second factor").
Two-factor sign-in, and who needs it
This is the item people meet most. Form submissions are personal data, and the easiest way into them is a reused password on the owner's account. So when a site collects data, the baseline checks two people: the owner of the workspace the site belongs to, who can read its submissions, and the person publishing, if that's someone else. If either lacks two-factor sign-in, publishing is refused with a message naming whose account it is. The fix is the same in both cases: turn on two-factor sign-in in Settings → Security with an authenticator app, keep the recovery codes, and publish again. The two-factor sign-in page explains the setup.
Where you see it
- Before publishing, in the release checklist card after each build, with a Turn on two-factor sign-in button when that's what's missing.
- At publish, as the reason a publish was refused, listing each failing item and its fix.
- After publishing, worked out again live on the site's public security report.
Limits
- Mostly met by design. Ten of the twelve items are met by how Anticode serves every site; only two-factor sign-in and field limits can fail for a particular site.
- Your other accounts aren't covered. The baseline can't see your email account, or the Slack or Sheets where submissions land. Protect those too.
- No exceptions. There's no way to publish a data-collecting site with two-factor sign-in off.
Questions people ask
Why does publishing ask me to turn on two-factor sign-in?
Your site has a form, so it collects visitors' data, and the baseline requires the account owner and the person publishing to use two-factor sign-in.
My teammate published and it was refused. Whose account needs it?
Both the workspace owner and the person publishing need two-factor sign-in when the site collects data. The message says which account is missing it.
Does a site with no forms need two-factor sign-in?
Not for publishing. The item shows as not applying, though turning it on is still a good idea for your account.
Can I see the baseline for a site after it's live?
Yes. It's on the site's public security report, recalculated whenever the report is opened.