Methodology
Every audit is passive and read-only. We request your site the same way a browser would, read the response the server already returns, and check a small set of well-known public paths. We never log in, never submit data, never run injection or exploitation payloads, and never store the pages we scan.
What we check
- Security headers — Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and information-disclosure headers.
- SSL / TLS certificate — validity, time to expiry, signature algorithm strength and trust-chain problems.
- HTTPS enforcement — whether plain HTTP redirects to HTTPS, downgrade exposure and redirect-chain length.
- Cookie security — Secure, HttpOnly and SameSite flags on each cookie set by the response.
- DNS & email security — SPF, DMARC and CAA records.
- Exposed files — a fixed allow-list of well-known sensitive paths (.env, .git, server-status) and the presence of a security.txt contact policy.
How the grade is calculated
Each site starts at 100 points. Every failed control subtracts a weight based on its severity — critical 40, high 20, medium 10, low 5 — and warnings subtract half. The score maps to a letter grade from A+ down to F, so two sites with the same grade have a comparable security posture.
What we never do
We do not brute-force directories, scan ports, fuzz inputs, or attempt to exploit anything. Deeper, intrusive testing only ever belongs on systems you own and have verified — and is out of scope for this free tool by design. That keeps the audit safe to run on any site and legal everywhere.
Limitations
An audit reflects a single response at a single moment. It is a strong first signal, not a full penetration test. A clean grade means the public-facing basics are in order — it does not certify that the application logic behind them is secure.