HTTP headers · security grades

Microsoft scores an F, my blog scores an A: what a security grade really measures

2026-07-20 · HardStacked · 7 min read

On July 20, 2026 we ran three domains through securityheaders.com, the free scanner that grades a site's HTTP response headers from A+ down to F. The results, in order: microsoft.com got an F. facebook.com got an A. And this blog, a static site with no team, no budget and no backend, also got an A.

The tempting headline is « small blog beats Microsoft at security ». That headline is wrong, and the ways in which it is wrong are more useful than the grades themselves. Each of those three letters has a reason behind it, and none of the reasons is « this company forgot ».

1. The badge measures one axis, not your security

First, what the scanner actually does. It sends one request and reads the response headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Six lines of text the server attaches to every page it serves. That is the entire exam.

It does not test whether the server is patched. It does not see the authentication, the firewall, the internal network, the people, or what happens after you log in. A site can serve six perfect headers in front of an unpatched application, and a site with an F can sit on an infrastructure your bank would envy. The grade measures the headers axis, all of the headers axis, and nothing but the headers axis.

So no, our A does not mean this blog is « more secure » than Microsoft. It means something narrower and still interesting: on this one measurable axis, the giant fails, and understanding why tells you how the web is actually built.

2. Why microsoft.com fails: the F is a business decision

Microsoft employs some of the best security engineers alive. Their homepage still serves no Content-Security-Policy worth grading. How?

Load microsoft.com with the network tab open and count what arrives: telemetry, advertising tags, A/B testing frameworks, multiple CDNs, embedded widgets. Dozens of scripts from dozens of third-party domains, managed by different teams on different release cycles. A strict CSP is a whitelist: every one of those sources would have to be enumerated, kept current, and would break the page the day a marketing team adds a tag the security team never heard about.

Faced with that, the owners of a marketing homepage make a rational call: no strict CSP. The F is not ignorance. It is the visible cost of a page built on dozens of third parties, accepted by people who decided the tracking stack was worth more than the header. You will find the same F on a large share of the corporate web, for the same reason.

3. Why facebook.com passes: nonces, the trick a static site cannot copy

Facebook's homepage carries as many scripts as Microsoft's, yet it serves a strict CSP and earns its A. The difference is a mechanism called a nonce, and it only works if your pages are generated by a server, per request.

On every single page load, the server invents a fresh random token and does two things with it: it stamps the token on every legitimate script tag, and it announces the same token in the CSP header.

The browser executes only the scripts wearing today's token. A script injected by an attacker was not there when the server stamped the page, so it carries no nonce and dies silently. The whitelist problem disappears: you no longer enumerate trusted domains, you mark trusted scripts, thousands of them if needed. Meta was one of the earliest large-scale CSP deployments, and this machinery is what their grade rests on.

The catch: a nonce must be unique per request, which requires a backend rendering each page. A static site like this one serves the same bytes to everyone; a « static nonce » would be a password taped to the door. Whatever a static site does, it will be a different path, which brings us to ours. But first, the most interesting line in Facebook's scan.

4. The header Facebook will not tighten, and why

Scan facebook.com and look past the grade at the detail: the weak spot is Referrer-Policy, the header that controls how much of the current URL leaks to the next site you click through to. This blog serves strict-origin-when-cross-origin; Facebook's policy is looser. The engineers who built the nonce machinery above could obviously ship a strict referrer policy before lunch.

They have not, and the likely reason is not technical. The referrer is attribution data: it tells the destination which page, which link, which campaign produced the click. For an advertising business, that data is not exhaust, it is inventory. A strict referrer policy would burn a little of their own product to buy a little of your privacy. We cannot see Meta's internal decisions from the outside; we can observe which header stayed loose at a company with every resource to tighten it, and that the loose one is the header their business model feeds on.

This is the actual lesson of the whole exercise: a site's security posture reflects its incentives at least as much as its competence. Microsoft's F is the cost of a tracking stack. Facebook's A stops exactly where the ad business begins. And a site with no data to sell can afford strictness everywhere, for free.

5. How a static site earns an honest A

Our A costs one file. Cloudflare Pages, like most static hosts, reads a _headers file at the root of the deployment and attaches its lines to every response. Ours declares the six headers, and you can check what any site really serves, including this one, from any terminal:

The reason the CSP can be strict is that the site is boring, in the best sense: no CDN, no external fonts, no tag manager, the fonts embedded in one CSS file, the favicon inlined. Almost everything resolves to 'self'. The two exceptions are earned and explicit: the contact form posts to its relay, and the analytics beacon reports home. Nothing else gets in.

One honest limit: our CSP allows 'unsafe-inline' scripts, because the page carries two small inline scripts and no backend to stamp nonces on them. That single allowance is what separates our A from an A+. The A+ route for a static site is hashing every inline script into the header, and every future edit to a script silently breaks the page until the hash is recomputed. For a site maintained by hand, we chose the grade that survives its owner: a durable A over a fragile A+.

What the three grades say together

One scanner, one afternoon, three letters: an F that is really a business decision, an A built on machinery a small site cannot copy, with a hole shaped exactly like an ad model, and an A that costs one file because the site behind it has nothing to sell but its configuration. The letters are shallow. The reasons are the whole story, and the reasons are always the same question: who profits from this gap staying open?