HTTP Security Headers: CSP, HSTS and the Rest Explained
What CSP, HSTS and the other HTTP security headers actually do, how to set them up, and which attack each one closes off, explained without the jargon.
rabbitclip teamPublished: 4 min read
Short answer
HTTP security headers are rules a web server adds to every response, telling the browser how to behave. CSP limits which sources scripts and images can load from, HSTS forces the browser to always use an encrypted connection, and smaller ones such as X-Content-Type-Options and Referrer-Policy close off risks that are just as real. None of them need custom code; a few lines in the server or CDN configuration are enough.
A law firm's website running a third-party advertising script without a properly configured CSP lets that script inject almost any code it wants into the page; on a page where a visitor is filling in a form, that risk is not abstract. Security headers limit what such a script can do from the outset.
What is an HTTP security header, and how does it work?
An HTTP security header is an extra instruction line the server sends with every response; the browser reads it and restricts the page accordingly. Headers do not change the page content, only what the browser is allowed to do with that content.
Adding them does not require writing a new feature; a few lines in the configuration of Nginx, Apache, Cloudflare or a framework such as Next.js is enough. Once set up correctly, they go out automatically with every page request.
What does Content-Security-Policy (CSP) actually do?
CSP defines which addresses a page is allowed to load scripts, images, fonts and styles from. Per OWASP's HTTP headers guidance, CSP is the one header that meaningfully mitigates code already injected into a page from running; that makes it one of the most effective defences against cross-site scripting (XSS).
The hard part of setup is listing every third-party resource the site genuinely uses, analytics, a font service, a payment provider; leaving one out breaks part of the page. This is why CSP is usually run in report-only mode first, the logs reviewed, before switching to enforcing mode.
What does HSTS (Strict-Transport-Security) guarantee?
HSTS tells the browser never to connect to a site over plain http:// again; the instruction is stored on the browser side, so even if a visitor types http into the address bar, the connection is upgraded to https automatically. This closes off a connection being stripped down to unencrypted mid-way, a man-in-the-middle downgrade.
MDN's recommended setup keeps the max-age long, around two years, covers subdomains too, and can be submitted to the preload list; but before joining preload, every subdomain needs to genuinely run on https, since coming off the preload list afterwards is not straightforward.
Setting up a baseline header set
For a small corporate site, the following five headers are a reasonable starting point; each one closes off a different risk.
- Content-Security-Policy: limits where scripts and resources can load from
- Strict-Transport-Security: keeps the connection encrypted at all times
- X-Content-Type-Options: nosniff, stops the browser guessing a file's type incorrectly
- Referrer-Policy: limits what page information leaks to other sites
- Permissions-Policy: restricts access to browser features such as camera and location
Testing headers and keeping them error-free
A misconfigured header can either break the page visibly or quietly disable a feature; both need testing before going live. The browser's developer console shows CSP violations directly; when a resource is blocked, the console names it and explains why.
Changes should be tried in a test environment first, then on a low-risk live page; rolling a change out across the whole site at once risks breaking an unexpected third-party integration.
Common mistakes
Security headers can become a set-and-forget setting; that leads to a breakage nobody notices until a new integration is added.
- Loosening CSP with unsafe-inline, which largely defeats the point of the header
- Adding HSTS to the preload list without testing it first
- Forgetting to update the CSP list when a new third-party script is added
- Setting headers only on the homepage and forgetting the rest of the site
HTTP security headers do not change how a site looks; they define what the browser is allowed to do with it. Setting them up is a one-time job, but keeping them current is not. A discovery call with rabbitclip is a good place to check which headers your current site actually has.
FAQ
Do security headers affect SEO?
Not directly, but headers such as HSTS that force HTTPS are an indirect positive signal for search engines that value secure connections.
Can setting up CSP break a working site?
Yes, if misconfigured. Testing in report-only mode first and reviewing the logs before switching to enforcing mode reduces that risk.
Where are these headers configured?
In the configuration of Nginx, Apache, Cloudflare or a framework such as Next.js; the syntax differs, the logic stays the same.
Does a small site actually need these headers?
Yes. Size does not matter here; any site running a form, a login page or third-party scripts faces the same underlying risks.
