Security headers: what each one actually buys you
Security headers usually get copied as a single block from some article. They work, nobody knows why, and the day one of them breaks something the whole block gets deleted.
What each one does
- Preventing content type sniffing: stops the browser from executing a file as a script just because its content looks like one. That closes off a whole class of upload-based attacks.
- Preventing framing: keeps another site from loading yours inside a transparent frame and tricking a user into clicking something they cannot see.
- Referrer policy: controls how much you reveal about where a visitor came from to the sites they go to. The default can leak private paths.
- Permissions policy: switches off camera, microphone, location and payment for everything that has no use for them. A profile site does not need a camera, so why leave that door open.
- Strict transport security: forces the browser to use HTTPS always.
- Content security policy: declares where code, styles and images may be loaded from.
Which one breaks your site
The content security policy. It is the strongest of the lot and the most dangerous to configure.
The safe route is to start in report-only mode. The policy runs without blocking anything and sends you reports on what it would have blocked. Collect those reports for a week, fix what needs fixing, then turn on enforcement.
Enforce on day one and you break your fonts, analytics and forms, and the header gets deleted instead of fixed.
The HSTS trap
Resist the urge to set the duration to a year right away. Start at a week. The header tells browsers to refuse plain HTTP for the whole period you declared, and you cannot take it back once you discover a subdomain that never got HTTPS. A week leaves room to catch that mistake. A year means the breakage stays live until the year runs out.
Related reading
Tell me what you want to build. Your first 15 minutes of consulting are free.
Book a consultation