What Are HTTP Security Headers? CORS, CSP, HSTS and More

HTTP security headers tell browsers how to behave when loading your site — blocking cross-origin abuse, enforcing HTTPS, preventing clickjacking, and more. One line of configuration can stop entire classes of attacks.

HTTP security headers are directives sent by a web server in the HTTP response that instruct the browser on how to behave when loading a page. They are one of the simplest, highest-impact security controls available — a single response header can prevent entire classes of attacks (XSS, clickjacking, protocol downgrade) with no changes to application code.


Why Security Headers Matter

Without security headers, browsers operate in a permissive default mode — allowing inline scripts, cross-origin resource loading, framing in iframes, and unencrypted connections. Attackers exploit these defaults. Security headers are the mechanism by which servers opt out of that permissiveness.


The Essential Security Headers

1. Content-Security-Policy (CSP)

What it does: Tells the browser which sources of content (scripts, styles, images, fonts) are legitimate. Anything not on the allowlist is blocked.

What it prevents: XSS attacks — even if an attacker injects a script tag, the browser refuses to execute it if the source is not trusted.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

Key directives: | Directive | Controls | |---|---| | default-src | Fallback for all resource types not explicitly listed | | script-src | JavaScript sources | | style-src | CSS sources | | img-src | Image sources | | connect-src | XHR, fetch, WebSocket connections | | frame-src | Which origins can be framed | | report-uri | Where to send CSP violation reports |

Avoid 'unsafe-inline' and 'unsafe-eval' — they negate most of CSP's protection. Use nonces or hashes instead.


2. Strict-Transport-Security (HSTS)

What it does: Tells browsers to only connect to the site over HTTPS-how-https-keeps-your-data-safe)-tls-how-https-keeps-your-data-safe), even if the user types http://.

What it prevents: protocol downgrade attacks and accidental HTTP connections that could expose cookies or credentials.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • max-age: How long (in seconds) the browser should enforce HTTPS-how-https-keeps-your-data-safe)-tls-how-https-keeps-your-data-safe)-only (1 year = 31,536,000)
  • includeSubDomains: Apply to all subdomains
  • preload: Request inclusion in the browser's built-in HSTS preload list (bypasses even the first HTTP connection)

> HSTS only works after the first HTTPS-how-https-keeps-your-data-safe)-tls-how-https-keeps-your-data-safe) connection. The preload list solves this — browsers refuse HTTP from day one.


3. X-Frame-Options

What it does: Controls whether the page can be embedded in an iframe.

What it prevents: Clickjacking attacks, where an attacker overlays a transparent iframe of your site over a malicious page and tricks users into clicking hidden buttons.

X-Frame-Options: DENY           # Never allow framing
X-Frame-Options: SAMEORIGIN     # Allow framing only by the same origin

> Modern alternative: use Content-Security-Policy: frame-ancestors 'none' which offers more granular control.


4. X-Content-Type-Options

What it does: Prevents the browser from MIME-type sniffing — guessing the content type of a response.

What it prevents: Attacks where an attacker uploads a file (e.g. a JPEG with embedded JavaScript), and the browser guesses it is a script and executes it.

X-Content-Type-Options: nosniff

5. Referrer-Policy

What it does: Controls how much referrer information is included in HTTP requests when navigating away from your site.

What it prevents: Leaking sensitive URL parameters (session-how-the-world-wide-web-works) tokens, search queries) to third parties.

Referrer-Policy: strict-origin-when-cross-origin

Common values: | Value | Behaviour | |---|---| | no-referrer | Never send referer header-cross-site-request-forgery-explained) | | strict-origin | Send only the origin (no path) for cross-origin requests | | strict-origin-when-cross-origin | Full URL for same-origin, origin-only for cross-origin |


6. Permissions-Policy (formerly Feature-Policy)

What it does: Controls which browser APIs and features the page (and embedded content) can access.

What it prevents: Malicious scripts or iframes accessing the camera, microphone, geolocation, or payment APIs.

Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=()

7. Subresource Integrity (SRI)

What it does: Browsers verify that a third-party resource (CDN script, stylesheet) has not been tampered with by checking its cryptographic [hash-cryptographic-hash-functions-explained)](/learning-center/what-is-sha-cryptographic-hash-functions-explained).

What it prevents: Supply chain attacks where a CDN is compromised and serves malicious scripts.


CORS: Cross-Origin Resource Sharing

CORS is not a security header that locks things down — it is a mechanism that selectively relaxes the browser's Same-Origin Policy to allow legitimate cross-origin requests (e.g. your React app on app.example.com calling an API on api.example.com).

The server indicates which origins it trusts:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Authorization, Content-Type

Common CORS mistakes:

  • Access-Control-Allow-Origin: with Access-Control-Allow-Credentials: true — browsers block this, but setting on authenticated endpoints is still too permissive
  • Reflecting the request's Origin header without validation — allows any site to make cross-origin requests
  • Allowing null origin — exploitable via sandboxed iframes

Preflight requests: For non-simple requests (custom headers, methods other than GET/POST, JSON body), the browser sends an OPTIONS preflight request first. The server must respond with appropriate CORS headers before the real request is sent.


Security Header Quick Reference

| Header | Grade if missing | Priority | |---|---|---| | Content-Security-Policy | C | High | | Strict-Transport-Security | C | High | | X-Frame-Options | D | High | | X-Content-Type-Options | D | Medium | | Referrer-Policy | B | Medium | | Permissions-Policy | B | Medium |

Test your site: securityheaders.com grades your headers and explains each missing one.


Key Takeaways

  • HTTP security headers are server-sent directives that harden browser behaviour
  • CSP is the most powerful — it prevents XSS by allowlisting trusted content sources
  • HSTS enforces HTTPS-how-https-keeps-your-data-safe)-tls-how-https-keeps-your-data-safe)-only connections and supports preloading into browsers
  • X-Frame-Options / CSP frame-ancestors prevent clickjacking
  • CORS is not a lockdown — it selectively opens cross-origin access; misconfiguration creates vulnerabilities
  • SRI ensures third-party scripts have not been tampered with on the CDN