What Your Website Security Grade Actually Means

You ran a security scan, got a D, and now you're staring at a checklist that mentions CSP, HSTS, SameSite, and a dozen other acronyms. What does that grade actually represent — and which fixes will move the needle? This is the website security grade explained without the marketing fluff: what scanners measure, why they weight things the way they do, and exactly what to change.

What a security grade actually measures

A website security grade is a composite score. Scanners like WebSentry break your site into measurable categories, test each one, and roll the results into a single A–F letter. The categories almost always include:

• TLS/SSL configuration — certificate validity, protocol versions, cipher suites
• HTTP security headers — HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
• Content Security Policy (CSP) — presence, strictness, use of unsafe-inline or wildcards
• Cookies — Secure, HttpOnly, SameSite attributes
• DNS hygiene — SPF, DKIM, DMARC, CAA records
• CORS — wildcard origins, credentialed requests
• Information leakage — server banners, exposed admin paths, verbose error pages

Each category is weighted. A missing CSP usually hurts more than a missing X-Permitted-Cross-Domain-Policies header because the real-world risk is higher. That's why two sites with the same number of "failed" checks can land on different letter grades.

What each letter means in practice

A — Production-ready

TLS 1.2/1.3 only, HSTS with a sensible max-age, a working CSP without unsafe-inline, cookies locked down, DMARC at p=quarantine or stricter. No glaring information leaks. This is where banks, SaaS dashboards, and anything handling auth should sit.

B — Solid, with gaps

Usually means one important control is missing or weak. Common culprits: CSP exists but uses unsafe-inline, HSTS is set but without includeSubDomains, or DMARC is at p=none. Fine for marketing sites, not great for anything with logins.

C — Acceptable for static sites only

TLS works, but headers are thin. No CSP, missing Referrer-Policy, cookies without SameSite. An attacker won't walk straight in, but XSS or CSRF surface area is wide open.

D and F — Active risk

D usually signals TLS misconfiguration (old protocols, weak ciphers) or completely absent headers. F means something is broken: expired certificate, mixed content, exposed .env file, or HTTP-only delivery. These sites get flagged by browsers and hurt SEO directly.

The fixes that move grades the most

Not every check is equal. If you're trying to climb from a C to an A, work in this order:

1. Fix TLS first

Disable TLS 1.0 and 1.1. Enable TLS 1.3. Remove any cipher suite with RC4, 3DES, or CBC-only modes. On Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

2. Add HSTS properly

Don't just add the header — commit to it. Start with a short max-age, verify everything works over HTTPS, then increase:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Only add preload when you're sure every subdomain serves HTTPS.

3. Ship a real CSP

This is where most sites lose points. A starter policy for a typical site:

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self'; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

If you can't avoid inline scripts immediately, use Content-Security-Policy-Report-Only first, collect violation reports, then enforce. Scanners penalise unsafe-inline and unsafe-eval heavily — and rightly so.

4. Lock down cookies

Every session cookie should have all three:

• Secure — only sent over HTTPS
• HttpOnly — not readable from JavaScript
• SameSite=Lax or Strict — blocks most CSRF

5. Clean up DNS

Add a CAA record so only your chosen CA can issue certificates. Publish SPF, DKIM, and DMARC even if you don't send email — it stops spoofing of your domain.

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  TXT  "v=spf1 -all"
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Why grades differ between scanners

Run the same site through three tools and you'll get three letters. That's because each scanner weights categories differently. SSL Labs is laser-focused on TLS. Mozilla Observatory weights headers heavily. WebSentry blends TLS, headers, CSP, cookies, DNS, and CORS into a single grade aimed at real-world web app risk, which tends to match what an agency or developer actually needs to fix before launch.

The takeaway: don't chase a specific letter on one tool. Look at the underlying checks. If three different scanners all flag the same missing CSP, that's the signal.

Common reasons sites get a worse grade than expected

• Headers set on the wrong response — security headers on /api but not on the HTML response, or vice versa
• CDN stripping headers — Cloudflare, Vercel, or Netlify edge rules overriding origin headers
• Wildcard CORS with credentials — Access-Control-Allow-Origin: * combined with Allow-Credentials: true is invalid and dangerous
• Mixed content — one http:// image reference drops the whole page's effective security
• Subdomains forgotten — www is hardened, api isn't

Turning a grade into a workflow

For agencies handling multiple client sites, treat the grade as a release gate, not a one-off audit:

1. Scan staging before every launch — fail the deploy if the grade drops
2. Re-scan production weekly to catch CDN changes, expired certificates, or plugin updates that strip headers
3. Document the target grade per site type — A for anything with auth, B minimum for marketing
4. Track changes over time so you can show clients measurable improvement

Run a free scan at websentry.dev to see your current grade, the exact checks behind it, and a prioritised list of fixes.