What This Tool Checks (and What It Doesn't)
This is a complete security audit, not a narrow single-purpose checker: it covers SSL/TLS certificate and protocol strength, every major HTTP security header (HSTS, CSP, X-Frame-Options, Permissions-Policy, cross-origin isolation), cookie flags, CORS misconfiguration, DNS/email security (SPF, DMARC, DKIM, DNSSEC, CAA, MTA-STS, TLS-RPT), exposed sensitive files, outdated JavaScript libraries, missing Subresource Integrity, and more: one report instead of several. It still deliberately stays out of general site health: SEO, Core Web Vitals/performance, accessibility, and broken-link checking aren't security concerns and belong to other tools. It also doesn't do open-redirect testing or port scanning, both of which need either site-specific knowledge or a different risk profile than the read-only checks here.
Why Exposed .git and .env Files Are Dangerous
A .git folder left publicly accessible lets anyone reconstruct a site's entire source history, including any secret ever committed, even one later "removed" in a newer commit. A .env file typically holds database credentials, API keys, and session secrets in plain text. Both are meant to be excluded from what a web server actually serves, but a misconfigured deploy or a missing .htaccess/nginx rule can leave them sitting at a predictable, publicly-guessable path; this check looks for exactly that.
What Mixed Content Actually Breaks
When an HTTPS page loads even one resource over plain HTTP, that single request travels unencrypted and can be intercepted or altered in transit. Modern browsers actively block mixed active content (scripts, stylesheets) and warn on mixed passive content (images). It's also a common leftover from a partial HTTP-to-HTTPS migration, where most of a site was updated but a few hardcoded http:// URLs were missed.
Subresource Integrity, Explained
When a page loads a script or stylesheet from a third-party CDN, it's trusting that CDN to never serve anything but the exact file it originally published. Subresource Integrity (SRI) closes that gap: the page specifies a cryptographic hash the fetched file must match, and if a compromised or misconfigured CDN serves anything different, the browser refuses to run it. It costs one integrity attribute per tag, and this tool checks for it on every third-party script and stylesheet it finds, then computes the real hash for you when one is missing.
SPF, DKIM, and DMARC, Explained
These three DNS records work together to stop someone else from sending email that looks like it came from your domain. SPF lists which mail servers are allowed to send on your behalf. DKIM lets a receiving server verify a message wasn't altered in transit, using a cryptographic signature. DMARC ties the two together and tells receiving mail servers what to do when a message fails both: reject it, quarantine it, or just let it through and report on it. Any one of the three alone is a weak defense; all three configured correctly is what actually stops domain spoofing.
Why This Tool Also Checks DNSSEC and Blacklist Status
DNSSEC cryptographically signs DNS responses so a resolver can verify they weren't tampered with in transit; without it, a network-level attacker can potentially redirect visitors to a fake copy of a site without either the visitor or the site noticing. A blacklist check (via Google Safe Browsing, when configured) answers a different question entirely: has this specific URL already been flagged for serving malware or phishing content, regardless of how well-configured its own security is otherwise. Both are domain-level trust signals that complement the page-content checks above.