What the security headers on our site actually do

Headers are instructions to the browser

A security header is a line the server sends before the page. The browser reads it and changes what it allows: what it runs, what it shows inside a frame, and what it shares about the page it came from. The visitor sees no difference in the page itself. The line is only a rule for the browser.

Each response from this site carries seven of these lines. The content policy is different: it sits inside the page, so the rule always travels with the exact bytes it was computed from.

The seven headers we send

Strict-Transport-Security: a max-age of one year. For that year, the browser contacts this site only over HTTPS. Our value leaves out includeSubDomains and preload, so it covers this host only.

X-Content-Type-Options: nosniff. The browser uses the file type the server declares and does not guess a type from the content, so a file sent as an image cannot run as a script.

X-Frame-Options: SAMEORIGIN. Pages from other sites cannot show this page inside a frame. Pages of this same site can.

Referrer-Policy: strict-origin-when-cross-origin. When a visitor follows a link to another site, the browser sends only the site name, not the full page address. Requests inside this site get the full address.

Permissions-Policy: camera=(), microphone=(), geolocation=(). The page and the frames in it cannot use the camera, the microphone or the device location.

Cross-Origin-Opener-Policy: same-origin-allow-popups. Pages from other sites cannot get a direct handle to this window. Pop-up windows this page opens can still reply to it, which sign-in and payment windows need.

X-Permitted-Cross-Domain-Policies: none. No cross-domain policy file may grant access to this site.

Two lines are left out on purpose. The payment permission is not sent, because a site page carries no payment. The DNS prefetch control is not sent for sites either.

The content policy inside the page

The content policy is not a header. It is one line in the page's own head element. default-src 'self' sets the rule for anything not named. object-src 'none' blocks plug-in objects. base-uri 'self' and form-action 'self' keep the page's base address and its form destinations on this site. Pictures, media and connections may also reach one outside storage host that the page names.

script-src 'self' is followed by eleven hashes, one for each script written into the page. A script file from this site may run. A script whose text does not match its hash does not run. The policy has no 'unsafe-inline' and no 'unsafe-eval'. Text in the page cannot run unless it is listed, and text cannot be turned into code while the page is open.

Inline event handlers such as onclick are blocked by script-src-attr 'none'. The live HTML carries none of them. Parts that used to need one now name a behaviour in a data-bws-on attribute, and one script on the page carries the table of behaviours.

style-src allows inline style, because page layout uses style attributes. Scripts get no such allowance. frame-ancestors is not in the page policy, so framing is controlled by the X-Frame-Options header.

The hashes are computed from the page's own bytes when it is built. If one character of a script changes, its hash no longer matches, and the page's own check reports that the script is not covered until the policy is built again.

What headers cannot do

• They protect the visitor's browser. They do not secure the server, the stored data, the site owner's account, or the code that runs on the server.
• A policy blocks what it does not list. A new inline script that is not in the list does not run until the policy is built again.
• They do not check what a person types. Input checks and sign-in limits belong on the server.
• A browser that does not support a line ignores it. The headers are one layer among several, not a complete defence.