Grade your site's HTTP security headers — A to F

The six HTTP security headers every site should set in 2026

Every HTTP response carries a set of headers — small key-value pairs the server sends before the page body. Most of them are routine: Content-Type tells the browser what's coming, Cache-Control says how long to keep it, Set-Cookie tracks the session. But a handful of headers are security-critical: they tell the browser to enforce a policy on the response itself. Skip them, and a perfectly-coded site becomes clickjackable, downgradeable, or vulnerable to cross-site scripting because the browser wasn't told to refuse.

1. Content-Security-Policy (the heavyweight)

CSP is a single header that says: "Browser, here is a whitelist of where scripts, styles, images, fonts, and connections are allowed to come from. Refuse anything else, even if the page tries to load it." A well-configured CSP stops most cross-site scripting because the attacker's injected tag simply won't load.

Example: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'; base-uri 'self'. That policy says: load scripts only from your own origin plus jsdelivr; load styles from your own origin plus inline (needed for most frameworks); block all plugins; lock down the base tag so an attacker can't redirect relative URLs.

CSP is the heaviest weight (20 points) in the grader because it covers the most common attack class. Sites that have no CSP and a single XSS bug lose customer data. Sites that have a strong CSP and a single XSS bug stay safe.

2. Strict-Transport-Security (HSTS)

HSTS tells the browser: "For this domain, always use HTTPS — even if the user types http:// or follows an HTTP link." Without HSTS, the first request to your site over plain HTTP can be intercepted by an active network attacker and rewritten to an HTTPS URL of their choosing (sslstrip). With HSTS, the browser refuses to make the plain-HTTP request at all.

Example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. One year, all subdomains, eligible for browser preload list. The preload flag means you've submitted to the Chrome HSTS preload list — the browser ships knowing never to make an HTTP request to your domain, before even checking headers.

3. X-Frame-Options (anti-clickjacking)

X-Frame-Options: DENY or SAMEORIGIN prevents your site from being framed by another site. Without it, an attacker can put your login page inside their malicious page, overlay it with a transparent "Click here to win" button, and capture your users' passwords when they try to log into what looks like your site.

Modern alternative: Content-Security-Policy: frame-ancestors 'none' or frame-ancestors 'self'. CSP frame-ancestors supersedes X-Frame-Options, but X-Frame-Options is still useful for older browsers. Set both.

4. X-Content-Type-Options: nosniff

One-line header, large impact. X-Content-Type-Options: nosniff tells the browser: "Trust the Content-Type I sent. Don't try to sniff the body to figure out if a .jpg is actually JavaScript." Without it, an attacker who can upload a file with a misleading extension can sometimes get it executed as the wrong MIME type. With nosniff, the browser refuses.

5. Referrer-Policy

When a user clicks a link from your page to another site, the browser sends the Referer header with the URL they came from. By default that includes the full path, which can leak sensitive information (private admin URLs, session tokens in URLs, internal search terms). Referrer-Policy: strict-origin-when-cross-origin sends the full URL on same-origin requests and only the origin (no path) on cross-origin requests. The right balance for most sites.

6. Permissions-Policy

Permissions-Policy (replacing the older Feature-Policy header) controls which powerful browser features your page can use: camera, microphone, geolocation, payment, USB, accelerometer, gyroscope, magnetometer. Example: Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=(). The () means "no origin can use this"; (self) means "only this origin can use this". If you don't use any of these features on a particular page, disable them entirely.

What to remove (the leak headers)

Just as important as adding the right headers is removing the leaky ones:

• Server: Apache/2.4.52 (Ubuntu) — tells attackers your exact software version. Replace with Server: WebServer or remove entirely.
• X-Powered-By: PHP/8.1.0 — same problem, worse. Most frameworks let you disable it.
• X-Generator: WordPress 6.2 — WordPress-specific leak, tells attackers which plugin CVEs to look for.

Modern attackers scan the internet with tools like Shodan and Censys looking for known-version sites. The more you leak, the faster they find you. A scan that shows nothing is harder to attack than a scan that shows everything.

Common mistakes when configuring CSP

CSP is the hardest of the six to configure correctly. Three patterns I see most often:

1. Unsafe-inline in script-src. Allowing inline scripts defeats most of the XSS protection because every XSS payload is by definition an inline script. Use nonces or hashes instead.
2. Wildcard source for scripts. script-src * allows scripts from any origin, including attacker-controlled ones. Use a narrow whitelist.
3. CSP that allows eval(). script-src 'unsafe-eval' permits eval(), which is how most obfuscated XSS payloads execute. Avoid it unless you have a hard dependency (some template engines need it).

If you can't get a strict CSP working immediately, use CSP in report-only mode first: Content-Security-Policy-Report-Only. The browser logs violations to your report-uri but doesn't enforce. Fix the violations, then switch to enforcing mode.

Why a header scan is necessary but not sufficient

A header scan tells you your browser-enforcement policy. It does not check your application code for SQL injection, your authentication for session fixation, your dependencies for known CVEs, or your server config for directory traversal. Run a header scan weekly (set a reminder), but pair it with:

• Dependency scanning: npm audit, pip-audit, snyk test, or GitHub's built-in Dependabot.
• Server-side log monitoring: tail auth logs for failed logins, 4xx spikes, unfamiliar user agents.
• Periodic manual code review by someone other than the original author.
• Annual penetration test by a qualified external auditor.

The header scan is your first line of defense — the cheap, fast, automated check that catches the most common misconfigurations. Everything else builds on top.

Related SiteTrace tools: /check, DNS lookup, SEO checker, HTTP headers viewer (for sites that pass the security check and want to see the rest).