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
- Content Security Policy Level 3 (primary documentation)
- RFC 6797, HTTP Strict Transport Security (rfc)
- WHATWG Fetch Standard, X-Content-Type-Options (whatwg)
- Referrer Policy (primary documentation)
- Permissions Policy (primary documentation)
- WHATWG HTML Standard, cross-origin policies (whatwg)
