Enter any domain. Get an instant A+ to F security grade based on 11 passive checks: HTTPS posture, security headers (HSTS, CSP, X-Frame-Options, and more), server disclosure, and email authentication (SPF, DMARC). Safe, legal, no port scanning.
Scanning domain security...
The scorecard runs 11 passive checks against the domain you enter, all from our server-side infrastructure. The checks cover three security surfaces: HTTPS posture (HTTPS enforcement, HTTP-to-HTTPS redirect, HSTS header), security headers (Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Server header disclosure), and email authentication (SPF and DMARC TXT records).
What "passive" means. No port scanning, no exploit attempts, no automated form submission, nothing that constitutes unauthorised access. The checks fetch publicly-served HTTPS responses (the same data any browser fetches when visiting the site) and query public DNS records (the same data any DNS resolver queries). Identical to what Mozilla Observatory, securityheaders.com, or hardenize.com surface — well-established passive security analysis. Use it on any domain freely; no authorisation needed.
How the grade is calculated. Each check is worth a fixed number of points based on its security weight. HTTPS enforcement is worth more than X-Content-Type-Options, for example, because the security impact is much larger. Points earned across all 11 checks sum to a raw score, normalised to 0-100, then mapped to a letter grade: A+ (95+), A (90-94), B (80-89), C (70-79), D (60-69), F (below 60). The Security Checks section on the results screen shows exactly which checks passed (✅) and failed (❌) along with the points each contributed.
Why these specific 11 checks. The check list reflects industry consensus on the highest-impact passive security configurations. CSP heavily weighted because it is the strongest single defence against cross-site scripting. HSTS weighted because it prevents downgrade attacks against HTTPS. SPF and DMARC included because email is part of your domain's security surface — a web-secure domain that is email-spoofable is not actually secure end-to-end. Server header disclosure included because version disclosure helps attackers fingerprint vulnerable software.
What this scorecard does NOT check. Application-layer vulnerabilities (XSS, SQLi, CSRF, IDOR, broken auth, business-logic flaws), backend security (database hardening, secret management, IAM), code quality and supply chain (dependency vulnerabilities, build pipeline security), operational practices (incident response readiness, backup strategy, employee security training), and any check requiring authentication. A high score means the public security posture is well-configured — it does not mean the application is bulletproof. For application-layer testing, use a scanner like OWASP ZAP or commercial DAST tools.
Before pushing a new site or major redesign live, run the scorecard against staging or production. Failed checks become a launch blocker if the domain is customer-facing. Most launches ship with at least 2-3 missing security headers — fixing them before launch is much easier than retrofitting after the site has live traffic and configuration changes need careful coordination.
You are evaluating a SaaS vendor for procurement. Run the scorecard against their primary domain plus their auth/login subdomain. A vendor selling enterprise security products with a D-grade scorecard is signalling something about their internal security posture that the marketing site does not. Pair this with their CVE history (via the CVE Explorer Hub) and you have a 5-minute baseline of their public security maturity.
For bug-bounty engagements where security headers are in scope (most are), the scorecard quickly identifies which headers are missing. Missing security headers are sometimes valid bug-bounty findings on their own (especially for higher-value targets) and the failed checks help prioritise which areas to test more deeply — a missing CSP often correlates with poorly-considered XSS protection elsewhere in the application.
Before a security-focused content audit (writing a "we take security seriously" page, updating trust documentation, preparing for an audit or compliance review), run the scorecard against your domain. The grade is concrete data you can either claim publicly or fix before claiming. Marketing claims about security that contradict an easily-runnable public scorecard create credibility risk; fixing the gaps first costs a day, not making the claim costs nothing.
For developer onboarding or general technical-literacy training, the scorecard makes abstract security concepts concrete. Engineers can run it against their own projects, see the missing headers, read the explanations, fix them — concrete, visible, immediate feedback loop. Much more effective than abstract security training that does not connect to anything they actually own and operate.
A+ means the 11 passive checks all pass. It does NOT mean the application is uncrackable. The scorecard cannot test XSS, SQLi, broken auth, IDOR, business logic flaws, backend security, or anything requiring authentication. High score is a necessary but not sufficient condition — sites with A+ scorecards still get breached via application-layer issues the scorecard cannot see.
Security headers are configurations. Security architecture is design — defence in depth, principle of least privilege, secure defaults, threat modelling. The scorecard measures the configurations layer; it cannot measure the architecture layer. A site with poorly-architected authentication can still get an A+ scorecard. Configurations matter; architecture matters more. Both need work.
Email authentication is part of your domain's security posture. A well-secured website on a domain that is trivially email-spoofable means attackers can phish your users by sending mail claiming to be from you. The whole-domain attack surface includes both web and email; the scorecard treats them as integrated for this reason. Add SPF and DMARC even if you do not actively send much mail.
If you are behind Cloudflare/CloudFront/Fastly, the scorecard measures the response visitors actually receive — which is the CDN edge response, not your origin response. If your CDN adds security headers via Transform Rules/Workers, those credit the score. If the CDN just proxies origin headers, your origin's config is what gets graded. Know which is which before deciding where to fix issues.
"We have an A+ Hacker Scorecard rating" is technically true if you do, but it claims more than the scorecard actually measures. The score reflects passive web-headers and DNS configuration, not application security or operational maturity. Use the score as evidence of basic hygiene; do not extrapolate to claims about overall security posture.
Configurations drift. New deploys can revert security headers if not properly templated. CDN rule changes can affect what visitors actually receive. New subdomains may not inherit the parent domain's security configuration. Re-run the scorecard quarterly or whenever you make significant infrastructure changes — particularly after CDN migrations or origin changes.