Every time SecureShield scans one of your websites, part of what it's looking at is a set of six HTTP response headers. Miss all of them and you'll see an F. Get all six right and you're looking at a 100. Neither number tells you much on its own — so here's what each header is actually defending against, in the order we weight them.
Content-Security-Policy
25 pointsThis is the header that carries the most weight in the score, and for good reason: it tells the browser exactly which sources it's allowed to load scripts, styles, and other resources from. Without it, if an attacker manages to inject a <script> tag into your page — through a comment field, a query parameter reflected without escaping, anything — the browser will happily run it. CSP is the header that says "no, only run scripts from these origins," which turns a successful injection into a dead end instead of a working exploit.
Strict-Transport-Security
20 pointsHSTS tells the browser to never load your site over plain HTTP again, even if someone types http:// or clicks an old link. Without it, that first request is a small window where an attacker on the same network — public WiFi is the classic case — can intercept the request before it gets redirected to HTTPS. HSTS closes that window by making the browser rewrite the request to HTTPS before it ever leaves the device.
X-Frame-Options
20 pointsThis one stops your site from being loaded inside an <iframe> on someone else's page — the classic "clickjacking" setup, where an attacker overlays your real login button under an invisible frame and a transparent decoy on top of it. Set this to DENY (or use frame-ancestors in your CSP) and browsers simply refuse to render your page in a frame at all.
X-Content-Type-Options
15 pointsSet to nosniff, this stops browsers from guessing a file's content type based on its content instead of trusting the Content-Type header you sent. That guessing behavior — MIME sniffing — is how a file uploaded as an "image" can end up executed as a script in some edge cases. One line, and that entire class of attack is off the table.
Referrer-Policy
10 pointsEvery time someone clicks a link from your site to another one, the browser can send the full URL they came from — including query strings, which sometimes contain tokens, session IDs, or search terms you didn't mean to share. A Referrer-Policy like strict-origin-when-cross-origin trims that down to just your domain when the destination is a different site.
Permissions-Policy
10 pointsThis restricts which browser features — camera, microphone, geolocation — your page (and anything embedded in it, like a third-party ad or widget) is allowed to request. Most sites use none of these. Explicitly disabling them means a compromised third-party script embedded on your page can't quietly ask for camera access either.
SecureShield fingerprints what's actually serving your site — Vercel, Netlify, Render, or a generic nginx/Apache box — from response headers those platforms add themselves. That's what lets it hand you an exact, ready-to-paste snippet for whatever's missing, instead of a generic checklist you have to translate into your own stack.
What that looks like in practice
If your site runs on Render, for example, and you're missing HSTS and CSP, the fix SecureShield generates looks like this — dropped straight into server.js, before your routes:
app.use((req, res, next) => {
res.setHeader("Strict-Transport-Security", "max-age=63072000; includeSubDomains; preload");
res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;");
next();
});On Netlify it's a _headers file; on Vercel it's an entry in vercel.json; on nginx or Apache it's a couple of add_header or Header set lines. Same six headers, different syntax depending on where the site actually lives.
Want your own score?
Add a website to SecureShield and get a graded breakdown of all six headers in under a minute.
Get Started