Backend Study Lab

Backend

Secure HTTP Headers Explained for Backend Developers

Learn practical secure HTTP headers for backend apps, including HSTS, CSP, X-Content-Type-Options, frame protection, referrer policy, and cookie-related limits.

By CloveCode Studio Jun 30, 2026 Updated Jun 30, 2026 4 min read

Secure HTTP headers are response headers that tell browsers how to handle your pages, scripts, frames, content types, referrers, and transport security.

They do not replace authentication, authorization, input validation, or safe rendering. But they can reduce the blast radius of common web security mistakes.

Quick answer

Backend developers should understand these headers first:

  • Strict-Transport-Security
  • Content-Security-Policy
  • X-Content-Type-Options
  • X-Frame-Options or frame-ancestors in CSP
  • Referrer-Policy
  • Permissions-Policy
  • Secure cookie attributes such as HttpOnly, Secure, and SameSite

Start with a practical baseline. Then tighten policies only after testing real pages, login flows, OAuth redirects, embedded widgets, analytics, ads, and third-party scripts.

Why security headers matter

Browsers have many security features, but the server often needs to opt in or provide policy details.

Security headers can help with:

  • Enforcing HTTPS.
  • Reducing MIME-sniffing surprises.
  • Limiting clickjacking.
  • Controlling referrer leakage.
  • Restricting powerful browser APIs.
  • Reducing XSS impact with a careful CSP.
  • Making cookie behavior safer.

Headers are especially useful because they work at the browser boundary. If a page is loaded by a real user, the browser can enforce policies before application code handles everything perfectly.

Common secure headers

HeaderMain purpose
Strict-Transport-SecurityTells browsers to use HTTPS for future requests.
Content-Security-PolicyRestricts where scripts, styles, images, frames, and other resources can load from.
X-Content-Type-Options: nosniffPrevents MIME type sniffing for some resource types.
X-Frame-OptionsHelps prevent clickjacking in older/simple setups.
Referrer-PolicyControls how much referrer information is sent.
Permissions-PolicyLimits access to browser features such as camera, microphone, and geolocation.
Set-Cookie flagsControls cookie transport, JavaScript access, and cross-site behavior.

The right values depend on your application. A documentation site, admin console, embedded app, and OAuth callback page may need different tradeoffs.

HSTS

Strict-Transport-Security tells browsers to use HTTPS for your site.

Example:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS helps prevent accidental HTTP access after a browser has seen the header. It is useful for production HTTPS sites.

Be careful with includeSubDomains and preload behavior. If a subdomain is not ready for HTTPS, an aggressive HSTS policy can break access.

Content Security Policy

Content Security Policy, or CSP, is one of the most powerful security headers and one of the easiest to break accidentally.

A strict CSP can reduce the impact of XSS, but only if it matches how your site actually loads scripts, styles, images, fonts, frames, and APIs.

Example starter shape:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

This is not a universal copy-paste policy. Sites using analytics, ads, embedded videos, OAuth widgets, or payment scripts need explicit allowances.

For a content/tool site, document the policy and revisit it when adding Google Analytics, AdSense, newsletter scripts, affiliate scripts, or embedded demos.

Clickjacking and frames

Clickjacking happens when an attacker places your page inside a frame and tricks users into clicking something they did not intend.

Two common defenses:

X-Frame-Options: DENY

or CSP:

Content-Security-Policy: frame-ancestors 'none'

Use frame-ancestors in CSP for more flexible modern control. Keep X-Frame-Options when you need a simple compatibility baseline.

If your app must be embedded, do not use DENY. Instead, allow only trusted parent origins and test the embedding flow carefully.

Referrer and permissions policies

Referrer-Policy controls what URL information is sent in the Referer header when users navigate away or load resources.

A practical default:

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

This avoids sending full sensitive paths to other origins while preserving useful origin-level referrer data.

Permissions-Policy controls access to powerful browser features.

Example:

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

If your app does not use these capabilities, disabling them is a clean default.

Cookie security is configured through Set-Cookie attributes rather than a separate security header.

Example:

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/

Useful flags:

  • HttpOnly prevents JavaScript from reading the cookie directly.
  • Secure sends the cookie only over HTTPS.
  • SameSite controls cross-site cookie behavior.

Read SameSite Cookies Explained and Session Fixation Explained before changing session cookie behavior.

Common mistakes

The first mistake is copying a strict CSP from another site without testing your own scripts and embeds.

The second mistake is using headers as a substitute for output encoding, authorization checks, and safe session design.

The third mistake is enabling HSTS with includeSubDomains before every subdomain supports HTTPS.

The fourth mistake is setting duplicate or conflicting headers at the CDN, reverse proxy, and application layer.

The fifth mistake is forgetting legal or product needs. Analytics, ads, newsletter providers, payment scripts, and affiliate scripts may require policy changes and consent review.

Practical recommendation

Start with a simple baseline:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

Add HSTS only after HTTPS is fully ready.

Add CSP gradually. Start in report-only mode when possible, review violations, then enforce a policy that fits the actual app.

Keep header configuration documented in one place. For Cloudflare Pages, that usually means _headers plus any dynamic headers from Pages Functions or Workers.

Read CSRF vs XSS for why headers are only one layer of browser security. Read CORS Explained for Backend Developers before mixing security headers with cross-origin API behavior.

For authentication-related browser controls, read SameSite Cookies Explained, JWT vs Session Authentication, and Session Fixation Explained. For the full security sequence, browse the Backend Security Learning Path and the Topics map.

Keep reading