Configure HTTP security headers deliberately

Connect each browser security header to a threat, deployment boundary, and safe verification process before auditing a live response.

  • security headers
  • browser security
  • policy

Start with the behavior you need to constrain

Security headers are response fields interpreted by user agents. They can reduce specific browser-side risks, but they do not patch vulnerable application code, authorize requests, validate content, or prove that an origin and its intermediaries are secure.

Define the intended behavior before choosing a value. A useful review asks which resources a document may load, whether it may be framed, how long a browser should force HTTPS, which capabilities it may expose, and what referrer data it may send. The correct policy depends on the actual application and every public delivery path.

Field or policy Primary control Important deployment risk
Content-Security-Policy Resource loading, script execution, framing, and related document behavior A copied source list can break required content or permit more than intended.
Strict-Transport-Security Future HTTP-to-HTTPS enforcement for a known host A long lifetime or includeSubDomains can make unprepared hosts unreachable.
X-Content-Type-Options: nosniff MIME-type checking for affected destinations Incorrect Content-Type values can cause legitimate resources to be blocked.
Referrer-Policy Referrer information sent by navigations and requests A policy can disclose more URL information than the product intends.
Permissions-Policy Availability of selected browser features An allowlist can disable a feature in the document or its embedded descendants.
COOP, COEP, and CORP Browsing-context and cross-origin resource isolation Partial deployment can break popups, embeds, or cross-origin resources.

Build Content Security Policy from an inventory

Content Security Policy is not a standard string to copy between sites. Inventory scripts, styles, images, fonts, connections, frames, forms, workers, and other resource types. Then express the smallest policy that supports the reviewed application.

Use Content-Security-Policy-Report-Only to observe a candidate policy before enforcement. Reports are evidence to review, not permission to automatically add every reported origin. Browser extensions, injected software, and obsolete paths can produce noise.

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

Expected result: compatible browsers monitor violations without enforcing this candidate policy. After reviewing required resources and reports, deploy an enforced Content-Security-Policy and keep monitoring changes.

Use nonces or hashes when required inline scripts cannot be removed. Avoid weakening a policy with broad sources or unsafe execution keywords merely to silence violations. The frame-ancestors directive controls who may embed the response and must be delivered in an HTTP field; a meta-delivered policy cannot provide that directive.

Stage HSTS as a transport commitment

Strict-Transport-Security tells a supporting browser to use HTTPS for future connections to a known host. The browser remembers this policy for max-age. The optional includeSubDomains directive extends it to subdomains.

Begin only after HTTPS, certificates, redirects, and recovery procedures are reliable. Use a short lifetime during observation and increase it deliberately. Do not add includeSubDomains until every current and delegated subdomain is prepared for HTTPS; the parent policy can otherwise make a separate service unreachable.

Strict-Transport-Security: max-age=86400

Expected result: after receiving this field over secure transport, a supporting browser treats the host as an HSTS host for one day. This does not secure an initial unknown HTTP connection or prove the certificate and DNS path are otherwise correct.

Keep type, referrer, and capability policies separate

X-Content-Type-Options: nosniff asks the browser to enforce compatible declared media types for affected request destinations. It works with correct Content-Type fields; it is not a replacement for them.

Referrer-Policy controls which referrer information accompanies outgoing requests and navigations. Choose it from the product’s navigation, analytics, privacy, and compatibility requirements instead of assuming the strictest value fits every workflow.

Permissions-Policy controls selected browser features for a document and its embedded descendants. Review the current feature names and defaults before shipping an allowlist because the policy is feature-specific and evolves with the platform.

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

Expected result: supported browsers apply MIME checking, limit cross-origin referrer detail, and disable the named capabilities for the document and its descendants according to each policy’s processing rules.

Add cross-origin isolation only for a concrete need

Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy form a related but specialized group. They affect browsing-context relationships and whether cross-origin resources can be loaded without explicit permission. Use them when an application needs those isolation properties, then test every popup, frame, worker, and cross-origin resource as a single compatibility contract.

These policies are not CORS replacements. CORS controls whether a browser shares a cross-origin response with script, while isolation policies change other browser relationships and resource-loading checks.

Verify the response at every delivery layer

Check the final public response, not only application configuration. A CDN, reverse proxy, framework, route, redirect, or error handler can add, remove, duplicate, or vary fields. Inspect representative HTML, assets, redirects, and error responses because a policy useful for one representation may be absent or inappropriate on another.

curl --head https://example.invalid/

Expected result: the response shows the fields delivered at that public hop. It does not prove browser enforcement, application security, upstream behavior, or coverage of other routes. Confirm browser behavior and application tests before treating the deployment as complete.

Primary sources