How Guardr Scores Websites
Guardr scans your website from the outside — the same vantage point an attacker has — and grades what it finds. No agents, no credentials, no access to your infrastructure. If a misconfiguration is visible from the public internet, Guardr will find it. If it isn't, Guardr won't pretend to know.
Score Calculation
Your Guardr score is a number from 0 to 100, calculated as a weighted average across five security categories. Each category scores 0–100 internally. The weighted average of those five scores becomes your overall score.
| Category | Weight | What we check |
|---|---|---|
| TLS / SSL | 28% | Protocol versions, cipher suites, certificate validity, chain trust, HSTS preload |
| Security Headers | 28% | Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy |
| Exposure Paths | 20% | Accessible .git, .env, phpinfo(), debug endpoints, backup files, and other sensitive paths |
| Cookie Security | 14% | Secure, HttpOnly, and SameSite flags on session and authentication cookies |
| DNS | 10% | DNSSEC validation, CAA record presence |
Grade Scale
| Grade | Score Range |
|---|---|
| A+ | 95 – 100 |
| A | 85 – 94 |
| A- | 75 – 84 |
| B+ | 65 – 74 |
| B | 55 – 64 |
| B- | 45 – 54 |
| C | 35 – 44 |
| D | 20 – 34 |
| F | 0 – 19 |
How Secret Scanning Works
Guardr fetches JavaScript files loaded by your public-facing pages and scans them for exposed credentials — API keys, tokens, private keys, and secrets that match known entropy and pattern signatures. Secret scanning results are reported separately from your main score and only affect your Exposure score if secrets are actually found.
Critical secret found
e.g. AWS root key, Stripe live secret key — Exposure category score is forced to 0, regardless of other findings.
High-severity secret found
e.g. third-party API key, OAuth token — Exposure category score is capped at 20.
No secrets found
Secret scanning has no impact on your score.
False Positive Risk
Pattern-based secret scanning produces false positives. A minified UUID, a placeholder string in a component library, or a public-facing analytics ID can trigger a match. Guardr surfaces these findings for human review — treat them as leads, not confirmed incidents. Before rotating a credential, verify it is live and actually secret.
How Exposure Path Checks Work
Guardr probes a list of paths that are commonly left accessible by accident —
/.env,
/.git/HEAD,
/phpinfo.php,
/wp-login.php, and others.
A confirmed exposure means the server returned the actual file content with a real HTTP 200 —
your .env variables, your Git history, your debug output.
That's an immediate finding worth acting on.
What "inconclusive (soft 200)" means
Some servers return HTTP 200 for every request — including paths that don't exist — by serving a generic
HTML fallback page instead of a proper 404. When Guardr detects this pattern, it cannot distinguish
"file is genuinely exposed" from "server always says 200." The finding is flagged as inconclusive rather
than confirmed or clear.
This is still worth your attention. It means your server is not returning correct status codes, which
makes it harder for crawlers, monitoring tools, and security scanners to reason about what actually exists.
The fix is to ensure your server returns a real 404 for paths that don't exist, rather than silently
serving a fallback page. Once that's in place, a rescan will either confirm an exposure or clear the finding.
Why Guardr Checks DNSSEC and CAA
DNSSEC
DNSSEC cryptographically signs DNS records so that resolvers can verify responses haven't been tampered with in transit. Without it, an attacker in a position to intercept DNS traffic could redirect your domain to a server they control — a DNS spoofing or cache poisoning attack. Guardr flags missing DNSSEC as low severity rather than medium or high because real-world exploitation requires a privileged network position and DNSSEC adoption remains low across the industry. It's advanced hardening — genuinely useful, but not the first thing to fix on a site that has more pressing issues elsewhere.
CAA Records
Certification Authority Authorization (CAA) records let you declare which certificate authorities are permitted to issue TLS certificates for your domain. Without CAA records, any CA in the world can issue a certificate for your domain — and a rogue or compromised CA could do so without your knowledge. Guardr flags missing CAA as low severity because the baseline risk is already mitigated by certificate transparency logs (any mis-issued certificate will appear publicly within hours) and because CA compromise is rare. CAA is a sensible extra layer, not an urgent gap. Most registrars and DNS providers support it with a single record addition.
Why these show up at all
Most header-only scanners don't check DNS at all. Guardr surfaces DNSSEC and CAA because they are observable from the public internet, they have clear remediation steps, and leaving them unchecked means a complete picture of your domain's security posture is missing. They're low severity — but low severity isn't the same as not worth knowing.
How Often Does Guardr Scan?
Guardr rescans monitored domains on a scheduled basis and surfaces score changes as they happen. One-off scans on the public tool reflect a point-in-time snapshot. If you've deployed a fix and your score hasn't updated yet, trigger a manual rescan from your dashboard.
Why Your Guardr Grade May Differ From Other Tools
vs. SecurityHeaders.com
SecurityHeaders.com grades exclusively on HTTP response headers. Guardr grades headers as one of five weighted categories (28%).
A site with perfect headers but an exposed .env file and weak TLS
will score an A on SecurityHeaders.com and land in C or D territory on Guardr. Different scope, different grade.
Additionally, Guardr weights the combination of headers holistically — a site with CSP deployed but misconfigured
(e.g. unsafe-inline with no nonce or hash) will lose partial points
rather than receiving full credit.
vs. Mozilla Observatory
Mozilla Observatory covers HTTP headers and some cookie behavior, with bonus points for features like subresource integrity and redirects. Its scoring is additive — you earn points for what you have. Guardr's scoring is subtractive — you start with full marks and lose points for what's missing or misconfigured. Mozilla Observatory also does not scan for exposed sensitive paths, DNS configuration, or client-side secrets. Sites with a clean header posture but exposed debug files will grade well on Observatory and poorly on Guardr.
vs. SSL Labs (Qualys)
SSL Labs is the most thorough TLS scanner available and goes significantly deeper than Guardr's TLS checks — handshake simulations, vulnerability detection (BEAST, POODLE, DROWN, etc.), and detailed cipher preference analysis. If TLS is your specific concern, run SSL Labs. Guardr's TLS category will catch weak protocols, expired certificates, and missing HSTS — but it is not a replacement for a dedicated TLS audit.
What Guardr Does Not Scan
Guardr is a configuration monitor, not a vulnerability scanner. It will not tell you whether your application has an injection flaw, an authentication bypass, or a logic error in your code.
Out of scope
- Application vulnerabilities — SQLi, XSS, IDOR, SSRF, and similar
- Authentication and authorization logic — login flows, session management, access controls
- Server-side software versions — Guardr does not fingerprint or banner-grab
- Internal or authenticated surfaces — anything behind a login wall is out of scope
- Infrastructure and cloud configuration — S3 bucket policies, IAM roles, firewall rules
- Email security — SPF, DKIM, and DMARC are outside Guardr's scope
- Third-party dependencies — npm/pip/composer package vulnerabilities
If you need coverage in these areas, pair Guardr with a dedicated DAST tool, a dependency auditor, and periodic penetration testing.
Methodology Principles
External only
We scan from the public internet. We never ask for credentials, tokens, or infrastructure access.
Reproducible
Any auditor can verify a Guardr finding by replicating the HTTP request or DNS query we made. There is no proprietary inference — only observable behavior.
Actionable
Every finding links to fix instructions specific to your platform — Cloudflare, Nginx, or Apache. A grade without a remediation path isn't useful.
Something looks wrong with your score?
Open a support ticket with your domain and we'll walk through the raw findings with you.
Email [email protected]