← All cybersecurity posts

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.

Not headers in themselves, but set via Set-Cookie. Use Secure, HttpOnly and SameSite on session cookies.

Headers to remove

  • X-Powered-By and detailed Server versions, which help attackers fingerprint your stack.
  • X-XSS-Protection, which is deprecated. Modern guidance is to omit it or set it to 0.

Summary table

HeaderRecommended starting value
Strict-Transport-Securitymax-age=31536000; includeSubDomains
Content-Security-PolicyStrict policy, test in report-only first
X-Content-Type-Optionsnosniff
X-Frame-OptionsDENY or SAMEORIGIN
Referrer-Policystrict-origin-when-cross-origin
Permissions-PolicyDisable 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.

Find what attackers can see, before they do.

AI pentesting agents test your web app, API and cloud, and every finding comes with evidence and a fix. First report in about 10 minutes.

Stay ahead of attackers.

New vulnerabilities, breach write-ups and practical fixes. A few emails a month.