Verifiedapp Blog
Security Headers

A complete, copy-paste security header set (and what each one does)

· 2 min read
#cheat-sheet#csp#hsts#security-headers

How to use this

Most security headers are set-and-forget one-liners. One — Content-Security-Policy — needs to match your site and should be rolled out carefully. Below is a complete set with sensible values and what each line actually does. Apply them at your server, CDN or framework, adjust the CSP to your real sources, and you have closed the most common header gaps.

The header set

Strict-Transport-Security

Strict-Transport-Security: max-age=63072000; includeSubDomains Forces browsers to use HTTPS only, closing the downgrade gap. Add preload once every subdomain is HTTPS-ready. (Two years, all subdomains.)

Content-Security-Policy

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self' The big one. Allowlists where resources may load from, neutralizing most cross-site scripting. This is a strict starting point — add the specific sources you use, prefer nonces over unsafe-inline, and test in report-only mode first.

X-Content-Type-Options

X-Content-Type-Options: nosniff Stops the browser from guessing a file's type, preventing attacks where a benign-looking response is treated as a script.

X-Frame-Options

X-Frame-Options: DENY Prevents your site being loaded in a frame elsewhere (clickjacking). Use SAMEORIGIN if you frame your own pages. The modern equivalent is frame-ancestors in your CSP, shown above.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin Sends only your origin (not the full URL) to other sites, so you do not leak paths or tokens embedded in URLs.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=(), interest-cohort=() Switches off powerful browser features your site does not use, shrinking the attack surface. List only what you actually need.

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy: same-origin Isolates your page from other windows it opens or that open it, protecting against a class of cross-window attacks.

The one that needs your attention

Every header here except the CSP can be shipped as-is. The CSP is different because it depends on what your site legitimately loads — your scripts, fonts, analytics, embeds. If you paste a strict CSP cold, you may block your own resources. So roll it out properly: start with Content-Security-Policy-Report-Only, collect what would be blocked, build the allowlist from reality, replace inline scripts with nonces, then enforce. The other six you can set today.

A note on order and placement

Set these as response headers for all your pages, ideally at the edge (server or CDN) so they apply uniformly. Re-check them after framework upgrades — header config has a habit of drifting when the stack changes underneath it.

Verify the result

Setting headers and correctly setting headers are different things, and a typo or a too-weak value looks fine from the page. An automated scan reads your live responses and confirms which of these are present, missing or weakly configured. Scan your site and check your header set landed.

Related reading

FAQ

Can I just paste all these headers and be done?
Six of them, yes — they are safe one-liners. The Content-Security-Policy is the exception: it must match what your site loads, so roll it out in report-only mode first to avoid blocking your own scripts, then enforce it.
Where should I set security headers?
Ideally at the edge — your web server or CDN — so they apply to every response uniformly. Framework-level config works too; the key is consistency across all pages, and re-checking after upgrades since header config tends to drift.
Do these headers slow down my site?
No. They are a few hundred bytes of response metadata with no measurable performance cost, while closing whole classes of attack. They are among the best security-per-effort changes you can make.

Keep reading