Reading Security Grades and Risk Scores in Subdomain Scans
How to interpret per-host security grades, risk levels and findings when reviewing subdomain scan results.
Core Concept
A per-host security grade condenses a set of individual checks — HTTPS enforcement, security headers, redirect behavior and more — into a single letter that gives a fast sense of configuration quality.
The risk level and findings that accompany it go a step further, translating those same checks into a plain-language read on what's actually missing and why it matters.
What Feeds Into the Grade
Grades are typically built from a checklist of security-relevant configuration signals observed on the host's response.
- Whether HTTPS is enforced and properly configured
- Presence of headers like Content-Security-Policy, X-Frame-Options and X-Content-Type-Options
- HSTS configuration, which is commonly weighted heavily since its absence weakens transport security guarantees
- Cross-origin policies such as COOP, COEP and CORP
- Referrer and permissions policy configuration
Why a "B" Grade Is Often Common
Missing HSTS configuration is one of the most frequently observed gaps, even on otherwise well-configured hosts, since it requires deliberate setup rather than being enabled by most default configurations.
One Missing Header, One Grade Drop
A host can pass nearly every other check and still land at a "B" simply because HSTS was never explicitly configured.
Reading the Risk Level
Risk level takes a broader view than the grade alone, factoring in exposure context — such as whether the host is classified as a public API or admin interface — alongside the raw configuration checks.
A low-risk classification on a host with a "B" grade generally means the missing items are worth fixing but don't represent an urgent exposure, while the same grade paired with a public-facing API classification might warrant faster attention.
Using Findings and Recommendations
Each finding maps to a specific, actionable recommendation — for example, a missing HSTS finding pairs with a direct recommendation to enable Strict-Transport-Security. This turns the scan output into a checklist rather than just a diagnostic.
Across many subdomains, findings that repeat consistently often point to a shared configuration template or infrastructure pattern worth fixing centrally rather than host by host.
Real-World Implementation
Security teams commonly use grade and risk distribution across an entire subdomain footprint to prioritize remediation work, tackling the highest-risk, most exposed hosts first rather than working alphabetically through a long list.
Tracking grade trends over time, across repeated scans, also provides a simple way to demonstrate whether security posture is improving across an organization's full external footprint.
Common Mistakes to Avoid
- Treating a single letter grade as the entire security assessment.
- Ignoring risk level and exposure context in favor of the grade alone.
- Ranking remediation work alphabetically rather than by risk and exposure.
- Overlooking findings that repeat across many hosts, missing a chance for a centralized fix.
- Assuming a high grade means a host has no meaningful risk at all.
- Not re-scanning after remediation to confirm the grade actually improved.
- Reading a grade behind a CDN or WAF as purely reflecting the origin application.
Best Practices Checklist
- Use risk level and exposure classification alongside the grade, not instead of it.
- Prioritize remediation by combined risk and exposure, not grade alone.
- Look for findings that repeat across hosts as candidates for a centralized fix.
- Follow the specific recommendation tied to each finding rather than guessing at a fix.
- Re-scan after remediation to confirm the grade and findings actually changed.
- Track grade distribution over time to measure posture improvement.
- Interpret grades on CDN or WAF-fronted hosts with that context in mind.
Frequently Asked Questions
What does a security grade actually measure?
It summarizes a checklist of configuration signals like HTTPS enforcement and security headers into a single letter.
Why is HSTS such a common missing item?
It requires deliberate configuration rather than being enabled by default in most standard server setups.
Is a low risk level the same as a high grade?
Not necessarily — risk level also factors in exposure context, so a host can carry a decent grade but still warrant attention based on what it exposes.
Should I fix every finding immediately?
Prioritize by risk level and exposure first — not every finding carries the same urgency, even if all are worth addressing eventually.
Can a grade change between scans without any changes made?
It shouldn't for a stable configuration, though transient issues or proxy-layer changes can occasionally shift results between scans.
Do all subdomains need an "A" grade?
It's a reasonable goal for public-facing, sensitive hosts, though the priority should scale with what each host actually exposes.
How do I know if a finding applies to many hosts at once?
Reviewing findings across your full subdomain list will often reveal repeated patterns worth fixing at the infrastructure or template level.
Check Your Subdomains' Security Grades
Run a scan and review grades, risk levels and findings across your subdomain footprint.
Launch Tool →