HTTP Security Headers Explained, in Plain English

What a security header actually is

This is HTTP security headers explained in plain English. Every time someone loads a page on your website, your server sends back two things: the page itself, and a short list of behind-the-scenes instructions called HTTP response headers. Most of those headers are housekeeping (what type of content this is, how long to cache it). A handful of them are security instructions: they tell the visitor's browser how to behave in order to protect that visitor from common attacks.

The important thing to understand is that headers are defensive, not active. They do not scan for malware, block hackers at your server, or fix vulnerable code. They close off whole categories of browser-side attack by setting ground rules: only talk to me over HTTPS, do not let other sites embed me, only run scripts from places I trust. The browser does the enforcing. Your job is simply to send the instructions.

Because they are passive and visible to anyone who requests your page, security headers are one of the things our free scan checks from the outside, with no plugin or login required. They are also one of the easiest wins in website security: most are a few lines of configuration, and getting them right moves the needle on your grade quickly.

The headers that matter, and what each one does

There are a lot of headers in the wild, but a small core set does most of the protective work. Here is the plain-English version of each.

• Strict-Transport-Security (HSTS): tells the browser to only ever connect to your site over HTTPS, even if someone types or clicks a plain http:// link. This shuts down a class of attacks where someone on the same network downgrades a visitor to an unencrypted connection and reads or tampers with the traffic. It is the single most valuable header for most sites.
• Content-Security-Policy (CSP): the most powerful and the fussiest. It tells the browser exactly which sources of scripts, styles, images and frames are allowed to load. A good CSP makes it very hard for an attacker to inject and run malicious JavaScript (a cross-site scripting, or XSS, attack), because the browser refuses to run anything that is not on your approved list.
• X-Frame-Options (or CSP's frame-ancestors): stops other websites from loading your pages inside a hidden frame. This blocks clickjacking, where an attacker overlays your real login or payment page under a decoy and tricks a visitor into clicking through.
• X-Content-Type-Options: a one-value header (nosniff) that stops the browser from second-guessing file types. Without it, a browser can be fooled into treating an uploaded image or text file as executable script.
• Referrer-Policy: controls how much of the current page address gets sent along when a visitor clicks a link to another site. Tightening this prevents leaking sensitive URLs (think password-reset or session links) to third parties.
• Permissions-Policy: lets you switch off browser features your site does not use, like the camera, microphone or geolocation, so a compromised script cannot quietly turn them on.

What a security-headers report is telling you

When you run a headers check, the report is doing something simple: it requests one of your pages, reads the headers that came back, and compares them against the core set above. A missing header shows up as a gap; a present but weakly configured header (for example, an HSTS line with too short a lifetime, or a CSP that allows everything) shows up as a partial pass.

Two cautions help you read the result honestly. First, presence is not the same as strength. A site can technically send a Content-Security-Policy that permits any source, which scores as present but protects against almost nothing. Second, headers are only one layer. A perfect header score does not mean the site is secure overall, it means the browser-side ground rules are in place. That is exactly why BadgerScan folds headers into a broader picture rather than treating them as a final grade.

You can see your own results in seconds with our security headers checker, or get them alongside your TLS certificate and email setup in the full free external scan. For the wider context of what an outsider can read off your site before they ever log in, see what attackers see outside WordPress.

The order to add them (lowest risk first)

Not all headers carry the same risk of breaking your site, so add them in this order. The first few are nearly always safe; the last one needs care.

Start with the low-risk, high-value headers: X-Content-Type-Options (nosniff), X-Frame-Options (or frame-ancestors 'self'), and Referrer-Policy. These rarely break a normal website and close real gaps immediately.

Next, add HSTS. Begin with a short max-age so you can confirm everything on your site genuinely works over HTTPS, then raise the duration once you are confident. Do not add the preload directive until you are certain, because it is hard to undo quickly.

Save Content-Security-Policy for last and expect to tune it. CSP is the one header that will visibly break things if you get it wrong, because it can block legitimate scripts, fonts and embeds along with the malicious ones. The safe approach is to run it in report-only mode first, watch what the browser would have blocked, add those legitimate sources to your allow-list, and only then enforce it.

On WordPress, headers are usually set in your server configuration, a security plugin, or your CDN. Whichever route you choose, the principle is the same: change one header, reload the site, confirm nothing broke, then move to the next. Our WordPress security guide walks through where these settings live, and the Ontario small-business security checklist puts headers in context with the other basics.

HTTP security headers explained: a start, not the finish line

Strong headers are genuinely worth doing, and they are cheap. But they only govern how browsers treat your site. They do nothing about the most common real-world cause of WordPress break-ins: vulnerable plugins. Plugins account for roughly 96% of WordPress vulnerabilities; only a handful are ever in core (Patchstack). And the volume keeps climbing: Patchstack recorded nearly 8,000 new WordPress vulnerabilities in 2024, about a 34% rise on the year before (Patchstack, via SecurityWeek).

That is the gap between an outside view and an inside view. A headers scan, a TLS check and an email-spoofing test all read your site from the outside. They cannot see which exact plugin versions you are running or whether any of them has a known, exploited flaw. BadgerScan Pro adds a read-only WordPress plugin that scans the inside (exact plugin, theme and core versions and their known CVEs, admin configuration, two-factor status, file integrity) and fuses inside and outside into one plain-English grade and one deduplicated fix-list. The plugin is read-only; BadgerScan never does penetration testing or active exploitation. The inside-outside scan explainer shows why both halves matter.

Treat headers as the polite, easy first chore. They tighten the browser-side rules in an afternoon and they make your report look healthier. Then keep going with the work that actually stops most breaches: keeping plugins patched and watching for known vulnerabilities.