Insights › Security

Security headers: the six your app needs and what each one protects

Security headers are HTTP response headers that tell the browser how to defend your visitors. A generated deploy sets none of them. Here are the six that matter, what each one does, and how to check they're actually being served.

Aug 8, 2026 · 6 min read

The short version

Security headers are HTTP response headers that tell the browser which defensive behaviors to enable. A generated deploy typically returns none of them. Each one is a one-line addition to your server or hosting config, and together they close six of the most common attack surfaces on the web.

The six headers

1. Content-Security-Policy

Tells the browser which sources of scripts, styles, images and connections to trust. Your primary defense against cross-site scripting. Without it, any injected script runs with full access to your domain. See the full CSP guide for directive-by-directive detail.

2. Strict-Transport-Security (HSTS)

Forces the browser to use HTTPS for every future visit to your domain. Without it, a first-time visitor who types yourapp.com into the address bar makes an HTTP request that can be intercepted before the redirect to HTTPS fires. The max-age tells the browser how long to remember this rule — at least one year (31536000), and includeSubDomains covers your subdomains too. See the HSTS guide for the full explanation.

3. X-Frame-Options

Prevents your page from being loaded in an invisible <iframe> on a malicious site — the classic clickjacking attack. DENY blocks all framing. SAMEORIGIN allows your own pages to frame each other but blocks external sites. The modern equivalent is CSP frame-ancestors, but X-Frame-Options still works in every browser and covers old clients.

4. X-Content-Type-Options

A one-value header: nosniff. It tells the browser not to guess the MIME type of a response. Without it, a browser might interpret a user-uploaded text file as an HTML page and execute scripts inside it. Set it on every response and forget about it.

5. Referrer-Policy

Controls how much of your URL is sent in the Referer header when a user clicks an outbound link. The safe default is strict-origin-when-cross-origin: it sends the full path when linking within your own site, but only the origin (domain) when linking to other sites. Without it, every outbound link leaks the full URL — including query parameters, session tokens, and internal paths.

6. Permissions-Policy

Restricts which browser APIs your site can access: camera, microphone, geolocation, payment handler, and more. A generated app ships with everything allowed. The minimum safe policy is camera=(), microphone=(), geolocation=(), payment=() — this denies access to every sensitive API. Enable them one by one as your app actually needs them.

How to check them

1
curl the live URL
curl -I https://yourapp.com prints the response headers. Look for each of the six headers above. If they're absent, your deployment isn't sending them — regardless of what your framework config says.
2
SecurityHeaders.com
Paste your URL. It scans the response and grades each header with a letter score and a plain-English explanation.
3
Check both www and bare domain
Your redirect chain might return different headers at each hop. The final response is the one that matters, but every hop should set HSTS.

Why the hosting platform matters

Headers are set by the server that responds to the request — and that's not always your application. A CDN, a reverse proxy, or a platform default can strip or override headers between your config and the wire. Vercel, Netlify and Cloudflare each have their own way of setting response headers. Check the deployed response, not the config file — the only measurement that counts is what the browser actually receives.

Actuant reads every security header from your deployed app's actual HTTP response and grades each one: present and correctly configured, present but weak, or absent.

Keep reading

Content-Security-Policy: what it protects, how to write one, and the mistake that makes it useless

A Content-Security-Policy tells the browser which scripts, styles and connections to trust — it's your primary defense against XSS. A generated app ships with none. Here's how to write one that's strong enough to matter and test it without breaking anything.

HSTS: the header that makes HTTPS stick

Without HSTS, the first visit to your domain goes over HTTP before the redirect to HTTPS kicks in — and that first request is unprotected. HSTS tells the browser to go straight to HTTPS on every future visit. Here's what it is, what the values mean, and why a redirect alone isn't enough.

security.txt: the one-page file that tells researchers how to reach you

security.txt is a standard that tells security researchers where to report vulnerabilities they find in your app. It takes two minutes to set up and it's the first thing a researcher checks. Here's what's in it and where it goes.