March 10, 2026 · 4 min · Carol
5 HTTP security headers your site probably doesn't have
Security headers are the cheapest and most underused defense on the web. Five you can turn on today without touching application code.
When a page loads in the browser, the server sends — along with the HTML — a series of invisible HTTP headers. Some of these headers exist to tell the browser: "hey, don't trust just anything, I'll guide you on what's safe here."
Without them, the browser runs in default mode, which is too permissive for the modern world. Here are five you can add without touching application code — just server config or middleware.
1. Strict-Transport-Security (HSTS)
Strict-Transport-Security: max-age=31536000; includeSubDomains
What it does: tells the browser "use HTTPS for this domain for X seconds". Even if the user types http://yoursite.com, the browser automatically switches to https:// without even making the insecure request.
Why it matters: without HSTS, the first access to a domain happens over HTTP (even if it redirects to HTTPS afterward). That opens a short window for an SSL stripping attack on hostile networks.
Caution: a high max-age + includeSubDomains is a heavy commitment. Start with 1 hour (3600), then 1 day, then 1 year. If you disable HTTPS on some subdomain later, it will break.
2. Content-Security-Policy (CSP)
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
What it does: controls where the browser may load resources from (scripts, images, fonts). Blocks script injection from unauthorized domains.
Why it matters: it's the strongest defense against XSS (cross-site scripting). Even if an attacker manages to inject <script> into your page, the browser refuses to run it if the domain isn't authorized.
Caution: strict CSP breaks things — inline scripts, eval, Google Fonts. Start permissive ('unsafe-inline' in script-src) and tighten gradually. Use report-only first: Content-Security-Policy-Report-Only: ... makes the browser report violations without blocking.
3. X-Frame-Options
X-Frame-Options: DENY
What it does: prevents your site from being loaded inside an <iframe> on other pages.
Why it matters: without it, an attacker can embed your site in a transparent iframe overlaid on fake buttons — clickjacking. The user thinks they're clicking "OK, accept cookies" on the attacker's site, but they're clicking "Transfer R$ 1,000" on yours.
Modern alternative: Content-Security-Policy: frame-ancestors 'none' does the same with more flexibility. Today you want both — some older browsers only read X-Frame-Options.
4. X-Content-Type-Options
X-Content-Type-Options: nosniff
What it does: stops the browser from "guessing" a file's type. If the server said Content-Type: text/plain, the browser treats it as text — not as an HTML script, even if the content looks like HTML.
Why it matters: without nosniff, attackers can upload a .txt file with <script> content and trick the browser into running it. With nosniff, the browser respects the declared Content-Type.
Caution: none. This header breaks nothing. If you don't have it yet, add it now.
5. Referrer-Policy
Referrer-Policy: strict-origin-when-cross-origin
What it does: controls how much information about the current URL is sent when the user clicks a link leaving your site.
Why it matters: without this policy, the Referer header leaks the full URL — including query strings that may carry tokens, emails, IDs. Imagine https://yoursite.com/reset?token=abc123 being sent to Google Analytics, to Facebook, to any link clicked on the page.
strict-origin-when-cross-origin is the best default: it sends the full origin for same-site requests, only the origin (no path) for cross-origin requests, and nothing for HTTP leaving HTTPS.
How to check right now
You can check manually by opening the browser DevTools → Network → click the document → Headers tab. But it's tedious to do for every page.
Tools that automate it:
- securityheaders.com — public check, gives an A-F grade
- Sentinela — the Headers probe checks the 5 above + CSP quality (unsafe-inline, wildcards, Trusted Types), HSTS preload, COOP/COEP, and flags disclosure (Server, X-Powered-By)
The minimum baseline
If you're only going to add one thing today, add:
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
These three break nothing and close the most obvious doors. HSTS and CSP deserve more care but the ROI is huge — especially CSP for apps that process sensitive data.
HTTP headers are literally the cheapest defense on the web. You change the server config, deploy, and it's done. There's no excuse not to have them.
Keep reading