What are HTTP security headers?

Security headers are HTTP response headers that tell the browser to switch on protections for your site, such as Content-Security-Policy, Strict-Transport-Security and X-Content-Type-Options. They do not fix bugs in your code; they limit what an attacker can do with one, and they cost a line of server configuration each.

Why it matters

Browsers ship strong defences that are off by default because turning them on can break old sites. Strict-Transport-Security (HSTS, RFC 6797) makes the browser refuse plain HTTP for your domain. Content-Security-Policy restricts where scripts may load from, which can stop many XSS bugs from running injected code. X-Content-Type-Options: nosniff stops the browser guessing file types, and frame-ancestors in CSP, or the older X-Frame-Options, stops other sites framing yours for clickjacking.

Missing headers are a configuration issue, which the OWASP Top 10:2025 files under A02, security misconfiguration. The OWASP Secure Headers Project keeps a maintained list of which headers to send and which to stop sending, such as headers that advertise the server's software version.

Example: checking the headers of CyberGym

One request shows a site's headers. This is CyberGym, the legal practice target, on 2026-10-24:

$ curl -sI https://cybergym.hackergpt.app/
HTTP/1.1 200 OK
Server: nginx
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Feature-Policy: payment 'self'
X-Recruiting: /#/jobs

Two protections are on: nosniff and a same-origin frame rule. Two are missing: there is no Content-Security-Policy, so nothing limits injected scripts, and no Strict-Transport-Security. Access-Control-Allow-Origin: * lets any site read responses that need no credentials, and Feature-Policy is the old name of Permissions-Policy. The X-Recruiting header is an Easter egg of the practice app, but on a real site any custom header is information an attacker reads.

Run the same command against your own site (https://your-app.example) and against each subdomain and API host, because headers are often set on the main site and forgotten on the others.

Common mistakes

  • Copying a strict CSP without testing it. A policy that blocks your own scripts breaks the site. Start with Content-Security-Policy-Report-Only and read the reports.
  • Adding HSTS preload casually. Preloading is hard to undo. Make sure every subdomain serves HTTPS first.
  • Setting headers on HTML only. APIs, file downloads and error pages need them too. Check responses from each layer.
  • Treating a header grade as a security grade. Perfect headers on an app with broken access control protect very little. Headers are one layer.

Related terms

Go deeper

Sources

Test only sites you own or have written permission to test. To practise without one, use CyberGym, a legal, deliberately vulnerable target. Practise on CyberGym.