HTTP Security Headers

Executive Overview

HTTP security headers are server-level directives that instruct browsers on how to handle your content securely. They are among the highest-impact, lowest-effort security improvements available — typically requiring no code changes, only server or CDN configuration. Missing headers are consistently cited in OWASP's Top 10 web application security risks.

Source: HTTP response header analysis performed on each WebsiteCoach audit.

Security Headers Explained

Content-Security-Policy (CSP)

CSP controls allowed resource sources and other browser behavior. Test report-only policies, then enforce a policy that fits your application.

Strict-Transport-Security (HSTS)

HSTS tells browsers to use HTTPS for a period. Confirm HTTPS coverage before extending max-age or including subdomains.

X-Content-Type-Options

The nosniff value limits MIME-type guessing. Send correct Content-Type headers as well.

X-Frame-Options

Controls whether other pages may frame this response. Check compatibility with legitimate embeds and CSP frame-ancestors.

Referrer-Policy

Controls referrer information sent with requests. Choose a policy that limits unnecessary URL disclosure while supporting required integrations.

Permissions-Policy

Allows or restricts browser capabilities such as camera and geolocation. Enable only the capabilities the page needs.

Cross-Origin-Resource-Policy (CORP)

CORP controls cross-origin use of a resource in applicable no-cors requests. Check external consumers before restricting access.

Cross-Origin-Opener-Policy (COOP)

COOP separates browsing contexts. Test popup-based authentication and payment integrations before enforcing isolation.

Cross-Origin-Embedder-Policy (COEP)

COEP places requirements on embedded cross-origin resources. Verify those resources support the necessary CORS or CORP policy.

Role-Specific Action Plan

How to inspect your live response headers

Inspect the final document request in your browser's Network panel. The command below uses GET and prints headers for each redirect; read the final response, not just the first hop.

1. Check the homepage, a content page, and an error response. Header rules may differ by path, status, or caching layer.
2. Compare each policy with the scripts, frames, images, and external services your application actually needs.
3. Make changes in staging, exercise login and payment flows, then verify the deployed response and browser console.

curl -sS -L -D - -o /dev/null https://example.com/

Example response and what each line does

Illustrative response for an HTTPS page. Adapt policies to your application; the presence of a header is not proof that the policy is effective.

HTTP/2 200
Content-Type: text/html; charset=utf-8
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
Permissions-Policy: camera=(), microphone=(), geolocation=()

Roll out CSP and HSTS carefully

Develop a Content Security Policy using report-only mode and inspect browser violations before enforcing it. A starting report-only policy is shown below. It does not block resources and does not send reports to a remote collector unless reporting is configured.

1. Inventory required origins and test scripts, styles, frames, forms, and API requests. Use nonces or hashes for inline scripts instead of broadly allowing unsafe-inline.
2. Move a tested policy to Content-Security-Policy to enforce it. Recheck the browser console and important user journeys.
3. For HSTS, confirm reliable HTTPS first. Test a short max-age before increasing it. Include subdomains or request preload only after reviewing every affected hostname.

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

• MDN Content Security Policy reference
• MDN HSTS reference
• Inspect other browser best practices