HTTP security headers and grade

The response headers that tell a browser what to allow. Together they decide how much an injected script or a framing attack can actually do.

• Help center

Security headers are instructions the server sends with every page. They do not fix bugs in your code; they limit what a bug can be used for. If an attacker manages to inject a script, a strict policy stops it loading code from elsewhere; if someone frames your site to trick clicks, the browser refuses to draw it.

How the grade is calculated

SiteScan reads the headers of the home page and grades six of them: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy. A header set correctly scores 2 points and is marked “Strong”; one that is present but too loose scores 1 and is “Weak”; a missing one scores 0. Out of 12 points, 11 or more earns an A, 9 a B, 7 a C, 5 a D, 3 an E, and anything below is an F.

Three more rows sit in this group without affecting the grade: HSTS preload, cross-origin reads (CORS) and the TRACE method.

Where to set them

Headers are added in the web server (add_header in nginx, Header always set in Apache), in the CDN's rules, or in the framework's middleware. Set them once for all responses, not page by page. The article on security headers has a ready-to-use set.