Web Security
HTTPS and Security Headers as a Production System
How TLS, canonical redirects, HSTS, CSP, framing, MIME, referrer, and permissions policies work together without breaking the application.
Author: Fahad Bin Shakir · Published: · Updated: · 12 min read
Introduction
A scanner can confirm that a response contains several security headers, but it cannot decide whether the policy matches the application. A copied Content Security Policy may block essential scripts, while an overly broad policy may satisfy a checklist without reducing risk. TLS and browser policy need to be designed, tested, and observed as part of the release.
The right starting point is a canonical HTTPS origin with known external dependencies. Each directive should have an owner and a reason, and every production response type should be checked rather than only the homepage.
Establish one canonical HTTPS origin
Issue a certificate that covers every hostname visitors can reach, renew it automatically, and monitor expiry. Redirect HTTP to HTTPS and redirect alternate hosts to the chosen canonical host in one hop. Preserve the path and safe query parameters so old links continue to reach the intended resource.
Test redirects from outside the hosting network and limit the chain. A rule that redirects www to itself creates an outage even though every response is technically a redirect. Canonical link elements support indexing decisions but do not replace server-side normalization.
Introduce HSTS only after HTTPS is reliable
Strict-Transport-Security tells supporting browsers to use HTTPS without attempting HTTP. Begin with a short max-age after confirming certificates, subdomains, redirects, and emergency renewal. Increase the duration gradually. includeSubDomains is safe only when every covered subdomain supports HTTPS.
Preload is a long-lived operational commitment rather than a score booster. Meet the browser preload requirements, understand removal delay, and obtain organizational approval before submitting a domain. A broken certificate on a preloaded host cannot be bypassed by visitors.
Build Content Security Policy from actual dependencies
Start with an inventory of scripts, styles, images, frames, fonts, connections, media, and workers. Use default-src 'self' as a baseline, then add the smallest specific sources each feature requires. Avoid wildcards and unsafe-eval. Prefer nonces or hashes when an application must execute controlled inline code.
Deploy a Report-Only policy first and collect violation reports without storing sensitive URLs unnecessarily. Remove browser extensions and known noise from analysis, fix legitimate dependencies, then enforce. Keep development-only hosts and debug allowances out of production.
Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; script-src 'self'; style-src 'self'; img-src 'self' data:; form-action 'self'; upgrade-insecure-requestsApply focused browser protections
X-Content-Type-Options: nosniff prevents certain MIME reinterpretation and is especially important for user-controlled files. Use frame-ancestors in CSP to control embedding; X-Frame-Options can remain as a compatibility layer when the requirement is simply DENY or SAMEORIGIN.
Referrer-Policy: strict-origin-when-cross-origin is a useful general default because it keeps full paths on same-origin navigation and sends only the origin across HTTPS sites. Permissions-Policy should disable browser capabilities the site does not use, such as camera, microphone, geolocation, payment, or USB.
Handle third-party scripts deliberately
Analytics, advertising, consent tooling, video, and support widgets often need several script, connection, image, and frame origins. Add only official endpoints required by the enabled feature. A script-src allowance alone may still fail when the script connects to a blocked endpoint.
Load optional systems only after the applicable consent decision and keep the privacy description aligned with real behavior. Review the policy whenever a vendor or integration changes. Third-party code runs with the page's authority, so business value and data handling matter as much as CSP syntax.
Verify every delivery path
Check document, API, error, redirect, static asset, and download responses through the public CDN. Hosting platforms may apply headers differently by route, and a reverse proxy may overwrite the application. Use browser console reports and automated header assertions, then test core actions such as sign-in, forms, downloads, media, and navigation.
Monitor certificate expiry, redirect loops, mixed content, CSP violations, and changes in external origins. Security headers are configuration under change control, not text copied once into a server file.
Deployment checklist
- Cover all public hostnames with monitored, automatically renewed certificates.
- Normalize HTTP and alternate hosts to one HTTPS origin without chains.
- Roll out HSTS gradually and treat preload as a long-term commitment.
- Inventory resources before designing CSP and test in Report-Only mode.
- Set nosniff, framing, referrer, and permissions policies intentionally.
- Keep optional vendor permissions and privacy disclosures synchronized.
- Verify headers and application behavior through the public CDN.