Website HTTPS Security Headers Guide: HSTS, CSP, Permissions Policy, and Safe Rollout

Overview

HTTPS encrypts traffic between a visitor and your website, but it does not automatically prevent every browser-based attack or unsafe integration. HTTP security headers tell browsers how to handle content, connections, framing, referrers, and selected device capabilities. They are most effective when treated as part of a broader deployment process that also includes certificate renewal, secure application code, dependency updates, access control, and monitoring.

Begin with headers that are broadly useful and low risk, then introduce stricter policies after inspecting your website’s assets and workflows. A small brochure site usually needs a simpler policy than a web application with payment tools, analytics, embedded media, customer support widgets, or multiple content delivery domains.

Headers do not replace a valid certificate or a complete HTTPS configuration. If HTTPS is not installed yet, follow a suitable Let’s Encrypt setup guide for Nginx or Apache first, then verify redirects and certificate renewal before enabling HSTS.

Checklist by scenario

For a mostly static website

• Confirm that every public hostname works over HTTPS and that HTTP redirects to the intended HTTPS URL.
• Add X-Content-Type-Options: nosniff.
• Set a deliberate Referrer-Policy rather than relying on an accidental server default.
• Use Permissions-Policy to disable camera, microphone, geolocation, and other capabilities the site does not use.
• Consider a basic CSP that permits only the site’s own resources, then add verified third-party origins one at a time.
• Enable HSTS only after checking that all important pages, subdomains, APIs, and redirects work correctly over HTTPS.

For a site with third-party scripts

• Make an inventory of analytics, tag managers, fonts, video players, payment tools, chat widgets, advertising services, and content delivery domains.
• Deploy CSP in report-only mode first where your tooling supports useful violation reports.
• Review each reported origin. Do not add a domain simply because it appears in a log; determine which page or feature needs it.
• Prefer nonces or hashes for controlled inline scripts rather than broadly allowing unsafe inline execution. This may require application changes.
• Re-test consent banners and scripts that load conditionally, since they may not appear during a normal first visit.

For a web application or login area

• Use CSP’s frame-ancestors directive to prevent unwanted framing, unless a documented integration requires it.
• Check that login, logout, password reset, file upload, and payment flows continue to work under the policy.
• Do not place secrets or session identifiers in URLs merely to simplify referrer handling.
• Apply headers consistently to error pages and application routes, not only the home page.
• Test administrative subdomains separately before extending HSTS coverage to them.

For Nginx or Apache deployment

Set headers at the layer that serves the final response. A reverse proxy, CDN, hosting panel, application framework, or web server may each add or replace headers. Avoid creating conflicting duplicate values unless you understand how the browser will combine them.

A simplified Nginx pattern might look like this:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy-Report-Only "default-src 'self';" always;

Apache uses equivalent Header always set directives, but the exact placement depends on whether configuration is managed in the virtual host or a directory-level file. Treat these examples as starting points, not a complete policy. Validate configuration syntax and inspect actual response headers before reloading a production server.

What to double-check

HSTS scope: HSTS affects browser behavior after the response is received. A setting that includes subdomains can affect services that are not yet ready for HTTPS. Do not use an aggressive scope or submit a domain to a preload program as a shortcut for testing. First confirm certificate coverage, redirects, monitoring, and renewal for every affected hostname. For related certificate planning, see this guide to Let’s Encrypt certificates for subdomains.

CSP completeness: A policy can block legitimate functionality or appear successful while missing pages that visitors rarely use. Test logged-out and logged-in states, mobile layouts, forms, downloads, error pages, and any feature that opens a new window or frame. CSP directives are precise: allowing a script origin does not necessarily permit inline code, dynamic evaluation, or every related resource type.

Permissions Policy syntax: List only capabilities your application requires. If a feature is delegated to an embedded frame, its origin may need to be named explicitly. Test on the actual page where the capability is used rather than assuming that a successful page load proves the policy is correct.

Server and CDN behavior: Compare headers at the origin and at the public URL. A CDN or hosting platform may cache an older response, remove a header, or apply a separate policy. Check both successful and error responses, and verify that redirects do not expose an unintended configuration.

Certificate operations: Header changes should not be made in isolation from certificate management. Confirm automated renewal and alerting before relying on HSTS. The Let’s Encrypt renewal automation guide covers the operational checks that keep HTTPS available.

Common mistakes

• Enabling HSTS too early: If even one required hostname cannot serve HTTPS, visitors may be unable to reach it after the browser remembers the policy.
• Starting with an untested CSP: A strict-looking policy is not useful if it breaks checkout, authentication, accessibility tools, or essential content. Use report-only mode and staged changes where possible.
• Using broad allowances: Values such as *, unrestricted inline scripts, or permissive framing can undermine the protection the policy is intended to provide.
• Copying a header list without understanding it: Headers vary by application. Remove obsolete or irrelevant directives rather than adding them to appear comprehensive.
• Testing only the homepage: Security headers need coverage across redirects, subdomains, APIs, static assets, authentication routes, and error responses.
• Forgetting rollback: Keep the previous server or CDN configuration, record the change, and know how to lower HSTS duration or disable a newly enforced CSP if a critical workflow fails.

When to revisit

Review your HTTPS security headers before a seasonal planning cycle, after a redesign, and whenever workflows or tools change. A new analytics tag, payment provider, font host, video service, CDN, reverse proxy, or deployment environment can change the correct CSP and Permissions Policy values. A domain migration or new subdomain is also a reason to reassess HSTS scope.

Keep a short header inventory with the policy owner, deployment location, required third-party origins, test URLs, and rollback steps. At each review:

1. Fetch the public HTTP and HTTPS versions of representative pages.
2. Inspect response headers, redirects, certificate status, and error responses.
3. Run the site’s important workflows in a clean browser session.
4. Review CSP reports and remove origins that are no longer needed.
5. Test certificate renewal separately from ordinary page testing.
6. Record the result and schedule the next review after the next planned infrastructure or application change.

For a broader investigation of certificate, redirect, and renewal failures, keep the Let’s Encrypt HTTPS troubleshooting checklist alongside this header review. The goal is not to collect the longest possible list of headers; it is to maintain a small, understood configuration that protects visitors without surprising the people who use or operate the site.