In short
Even a purely static site benefits from a small set of HTTP security headers — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and a sensible Referrer-Policy — configured once at the hosting or CDN layer, protecting against cross-site scripting, protocol downgrade attacks, and content-type sniffing regardless of the absence of server-side code.
Why static sites still need security headers
A static site has no database to inject into and no server-side code to exploit directly, but it still runs in a browser that executes any JavaScript present on the page, follows any redirect, and trusts whatever content type the server claims — all of which are attack surfaces that HTTP headers directly address, independent of whether the site's own code is dynamic.
Content-Security-Policy (CSP)
CSP restricts which sources of scripts, styles, and other resources a page is allowed to load from, which is the primary defense against cross-site scripting if a malicious script is ever injected (through a compromised third-party dependency, for instance). Start with a reasonably strict policy listing your actual legitimate sources (your own domain, specific analytics providers) and tighten it further once you've confirmed it doesn't break legitimate functionality.
Strict-Transport-Security (HSTS)
HSTS tells browsers to always use HTTPS for your domain, even if a user types http:// or follows an old link, preventing a downgrade to an insecure connection. Once you're confident your entire site (including all subdomains, if using the includeSubDomains directive) works correctly over HTTPS, this header is a straightforward, low-risk addition.
X-Content-Type-Options
Setting this to nosniff prevents browsers from trying to guess a resource's content type differently than what the server declares, which closes off a class of attacks that rely on a browser misinterpreting a file's type (treating an uploaded image as executable script, for instance).
Referrer-Policy
Controls how much information about the current page is sent in the Referer header when a user clicks a link to another site. A reasonably restrictive policy (strict-origin-when-cross-origin is a sensible default) limits how much of your site's internal URL structure and any sensitive query parameters leak to external sites via outbound links.
Permissions-Policy
Explicitly disables browser features (camera, microphone, geolocation) your site doesn't use, reducing the impact if a compromised third-party script somehow ends up on the page — it simply won't have access to capabilities you've explicitly disabled, regardless of what it attempts.
Where to configure these on a static site
Most static hosting platforms and CDNs support setting custom response headers at the hosting layer — through a configuration file, a dashboard setting, or middleware — without requiring any server-side application code. This means static sites get the same header-level protection as dynamic ones, configured once at the infrastructure layer rather than per-request in application code.
Verifying headers are actually applied
After configuring headers, verify them using your browser's network inspector or a dedicated header-checking tool — confirm the headers are present on the actual served responses, not just correctly configured in a file that isn't being applied, which is a common gap between intended and actual configuration.
A reasonable minimum set
For most static sites: a CSP scoped to your actual legitimate resource origins, HSTS once HTTPS is fully confirmed working, X-Content-Type-Options: nosniff, a restrictive Referrer-Policy, and a Permissions-Policy disabling unused browser features. This covers the majority of the practical security benefit available through headers alone.
More from our insights: How to Ship a Static Site With Zero Build Step · Why Your Site Doesn't Need a Framework.
Common questions
Does a static site really need security headers if it has no server-side code?
Yes — headers protect against browser-level attack vectors (script injection, content-type sniffing, protocol downgrade) that exist regardless of whether the site itself has dynamic server-side logic.
Can I set security headers without a backend server?
Yes — most static hosting platforms and CDNs support setting custom response headers at the infrastructure layer, without requiring any server-side application code.
How do I verify security headers are actually working?
Check the actual served response headers using your browser's network inspector or a dedicated header-checking tool, since a header can be correctly written in a configuration file but not actually applied to live responses.
