Public website security report for every site

Why publish a report at all

"Is this site safe?" is hard for a visitor or a client to answer from the outside, and most sites give them nothing to go on. A public website security report turns the question into something checkable: here are the rules every page meets, here is the exact policy the browser enforces, here's every outside host it loads from. Because the report is computed rather than written, it can't claim more than the pages actually do. A client signing off a site, or a cautious customer about to send their details, can look for themselves.

What's on the page

The report opens with a status, either All checks pass or the number failing, the time it was checked and when the site was last updated. Then, in order:

Checks run on every publish: The server's own checks, run again on every page of the site: a complete HTML document; no scripts, frames or plugins; no inline event handlers; no javascript: URLs; forms that post only to the site's own address; HTTPS for every URL. A check fails if it fails on any page, and the detail says which page.
Security baseline: Each item of the security baseline, marked as passing, failing or not applying to this site, with what Anticode does for it.
Integrity and malware scan: The result of the last scan of the site's files (Clean, Repaired or Taken down) and when it ran. The scan is described on the backups and integrity page.
What the pages contain: Each published page, the number of scripts and inline handlers, every form with its method and address, how many images have alt text, the outside hosts files load from, and the total size.
Headers every page is served with: The Content-Security-Policy word for word, plus nosniff, the referrer policy, the permissions policy that turns off camera, microphone, location and payment features, the cross-origin opener policy and HSTS.

Computed live, not stored

Nothing in the report is saved at publish and replayed. Each request reads the published pages from storage and works everything out again: the checks, the counts, the list of hosts. If a file were changed behind Anticode's back, the report would show the failure the moment someone looked. The JSON version at /.well-known/anticode-security.json carries the same data with open cross-origin access, so an agency, a client's IT team or a monitoring script can fetch it and compare. The HTML page asks search engines not to index it.

For app builds

A published app is a program, so its report is different. It shows the app code gate's security checks on the code the app runs, says the app runs in a sandboxed frame with no network of its own, and lists its forms as posts to the site's own inbox, sent by Anticode's runner rather than the app. The app code gate explains those checks.

Pointing people to it

In the builder's Console, the Security section has a switch, Show "Security-checked by Anticode" in the footer, that adds a small link to the report on your site. It's off unless you turn it on. You can also send the address directly: it's always your site's address followed by /.well-known/anticode-security.

What it doesn't tell you

It's not a certification or an audit. It shows rules the pages meet. It doesn't test your account, your email, or the services your forms send data to.
It covers the server-side checks. The builder's Sentinel runs twelve checks while you work; the report re-runs the ones that matter once a page is public, which is the same set publishing enforces.
It's public. Anyone can read the form addresses and hosts it lists, though they're visible in the page source anyway. There's no way to make it private.
It reflects published pages only. Changes still in the builder don't appear until you publish.

If a report ever shows a failure, the workflow on responding to a security report walks through what to check and fix. For the meaning of each header, see security headers explained.

Questions people ask

Where do I find my site's security report?

Add /.well-known/anticode-security to your site's address, on the anticode.dev subdomain or your own domain. Add .json for the machine-readable version.

Can the report say all checks pass when they don't?

No. It's worked out from the published pages every time it's opened, so it can only describe what is actually being served.

Do I have to show a badge on my site?

No. The footer link is an option in the Console's Security section and is off by default. The report exists either way.

Why does my report list Google Fonts?

Because the page loads its typeface from there. The report lists every outside host a page loads files from, so visitors can see exactly who their browser contacts.