Using HTTP Headers to Secure Your Site

Summary

A straightforward Static Buildpack app received an F, scoring 20/100 in Mozilla Observatory because several security response headers were missing, despite redirecting visitors to HTTPS with an Automated Certificate Management certificate. The walkthrough examines failures for Content Security Policy, HTTP Strict Transport Security, X-Content-Type-Options, X-Frame-Options and X-XSS-Protection, then configures them through the static.json headers collection. The CSP restricts resource origins, blocks inline scripts by default, and uses a SHA-256 hash to permit the Google Analytics inline script without adding unsafe-inline. HSTS uses max-age=63072000, includeSubDomains and optionally preload, while other headers supply MIME sniffing, iframe and legacy XSS protections. After the changes, the reported checks pass, the configuration reaches an A and is later described as A+; the final recommendation adds Referrer-Policy and omits opt-in HSTS preload.

Takeaways

1. 1

   A Content-Security-Policy can allow required external fonts, images, and analytics sources while retaining default self-hosting restrictions and frame-ancestors 'none'.

2. 2

   The inline Google Analytics script is authorized with a specific SHA-256 hash instead of the less secure 'unsafe-inline' directive; changing the script requires updating the hash.

3. 3

   The recommended final headers include HSTS with max-age=63072000 and includeSubDomains, plus nosniff, DENY, XSS blocking, and a Referrer-Policy; HSTS preload is excluded as opt-in.