HTTP Security Headers: A Practical Guide with Recommended Values
Security headers are instructions your server sends to browsers, telling them to enable protections. They take minutes to add and limit the impact of many vulnerabilities. Here are the ones that matter and sensible values to start with.
Strict-Transport-Security (HSTS)
Forces browsers to use HTTPS for your domain, preventing downgrade and cookie theft over plain HTTP.
Strict-Transport-Security: max-age=31536000; includeSubDomains
Start with a shorter max-age if you are unsure every subdomain supports HTTPS. Add preload only once you are confident, since removal from browser preload lists takes time.
Content-Security-Policy (CSP)
Controls where scripts, styles, images and frames can load from. A strict CSP is the strongest browser-side defence against XSS.
A starting point for many apps:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Real applications need to allow analytics, payment providers and CDNs. Use Content-Security-Policy-Report-Only first to see what would break. See our Content Security Policy guide for details.
X-Content-Type-Options
Stops browsers guessing content types, which can turn an uploaded file into executable script.
X-Content-Type-Options: nosniff
Framing protection
Prevents clickjacking.
X-Frame-Options: DENY
Or use CSP frame-ancestors, which is more flexible.
Referrer-Policy
Controls how much of the URL is sent in the Referer header to other sites, which can leak tokens or private paths.
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
Disables browser features you do not use, such as camera, microphone and geolocation.
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin isolation headers
For apps that need stronger isolation:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Test carefully, as these can break pop-up based login flows and embedded resources.
Cookie attributes
Not headers in themselves, but set via Set-Cookie. Use Secure, HttpOnly and SameSite on session cookies.
Headers to remove
X-Powered-Byand detailedServerversions, which help attackers fingerprint your stack.X-XSS-Protection, which is deprecated. Modern guidance is to omit it or set it to0.
Summary table
| Header | Recommended starting value |
|---|---|
| Strict-Transport-Security | max-age=31536000; includeSubDomains |
| Content-Security-Policy | Strict policy, test in report-only first |
| X-Content-Type-Options | nosniff |
| X-Frame-Options | DENY or SAMEORIGIN |
| Referrer-Policy | strict-origin-when-cross-origin |
| Permissions-Policy | Disable unused features |
Adding headers in Next.js
// next.config.js
module.exports = {
async headers() {
return [{ source: "/(.*)", headers: [
{ key: "X-Content-Type-Options", value: "nosniff" },
{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
{ key: "X-Frame-Options", value: "DENY" },
] }];
},
};
Checking your headers
SecurityInfinity checks security headers across every domain and subdomain it discovers, not just your homepage, and tells you exactly which values to set. Start free.
Frequently asked questions
Are missing security headers a serious vulnerability?
Usually low severity on their own, but they remove protections that limit the impact of XSS, clickjacking and downgrade attacks.
Will adding CSP break my site?
It can if the policy is too strict. Deploy in report-only mode first and adjust before enforcing.
Do security headers improve SEO?
Not directly, but HTTPS and a secure site are positive signals, and avoiding compromise protects your rankings.