Security

Headers, TLS, bot exposure, and common vulnerability signals across your public surface.

Public-facing security posture: response headers, TLS, DNS/email auth, and known vulnerability signals.

Header configuration quality is graded, not just presence - a misconfigured Content-Security-Policy can be worse than none at all.

Security headers

Check	Passes when
Content-Security-Policy set	Header present with a valid directive
Strict-Transport-Security (HSTS) set	max-age ≥ 15552000 (180 days)
X-Frame-Options set	DENY or SAMEORIGIN
X-Content-Type-Options set	nosniff
Referrer-Policy set	Any valid value
Permissions-Policy set	Any valid value
Server / X-Powered-By hidden	Version not disclosed

Verify these yourself with curl -I https://your-domain.com.

TLS and certificate

Check	Passes when
TLS 1.2 or 1.3 only	No TLS 1.0 / 1.1 offered
Certificate valid and trusted	Valid chain to a trusted root
Certificate expiry	More than 30 days remaining
Strong ciphers only	No RC4 / 3DES
HTTPS redirect from HTTP	301 or 308 to https://

DNS and email authentication

Check	Passes when
SPF record present and valid	v=spf1 ending in ~all or -all
DMARC policy set	p=reject scores full; p=quarantine partial
DKIM configured	Valid DKIM selector record
CAA record present	CAA restricts which CAs may issue

These matter even if you don't send email from the domain - without SPF and DMARC, anyone can spoof it.

Known vulnerabilities and secrets

Check	Passes when
Zero Critical / High CVEs	No High-or-above findings
No secrets in public JS bundles	Zero matches from the secret scan

These carry the heaviest weight in the category. A live API key committed into a client-side bundle is already public - treat it as compromised, rotate it, and move it server-side.

Rotate, don't just remove

Deleting a leaked key from your bundle doesn't invalidate it. Anyone who already scraped the file still holds a working credential until you rotate it.