# What are HTTP security headers?

Canonical: https://hackergpt.org/learn/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

- [Cross-site scripting (XSS)](https://hackergpt.org/learn/xss/)
- [OWASP Top 10](https://hackergpt.org/learn/owasp-top-10/)
- [Attack surface mapping](https://hackergpt.org/learn/attack-surface-mapping/)
- [Penetration testing](https://hackergpt.org/learn/penetration-testing/)

## Go deeper

- [Security checklist for vibe-coded and indie SaaS apps](https://hackergpt.org/blog/vibe-coded-app-security-checklist/)
- [Web Security](https://hackergpt.org/blog/web-security/)
- [HackerGPT features: see what your site exposes](https://hackergpt.org/features/)

## Sources

- [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/)
- [OWASP HTTP Headers Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
- [MDN: Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
- [RFC 6797: HTTP Strict Transport Security](https://www.rfc-editor.org/rfc/rfc6797)
- [OWASP Top 10:2025 A02 Security Misconfiguration](https://top10.owasp.org/2025/A02_2025-Security_Misconfiguration/)

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](https://cybergym.hackergpt.app).