Security
Check Your Security Headers
Inspect the HTTP response headers that protect visitors from common browser attacks.
Problem: Your website is missing browser-level protections that are free to enable.
Security headers instruct the browser how to treat your pages. We request your URL and report which protective headers are present, missing or weakly configured.
What we'll check
- Strict-Transport-Security (HSTS)
- Content-Security-Policy
- X-Content-Type-Options
- Referrer-Policy
- X-Frame-Options / frame-ancestors
- Permissions-Policy
- Server and technology disclosure headers
What each header does
- Strict-Transport-Security — forces browsers to use HTTPS for your domain, blocking downgrade attacks.
- Content-Security-Policy — restricts which scripts and resources may load, the strongest defence against XSS.
- X-Content-Type-Options: nosniff — stops browsers guessing content types.
- Referrer-Policy — controls how much URL data leaks to other sites.
- X-Frame-Options / frame-ancestors — prevents your pages being framed for clickjacking.
- Permissions-Policy — disables browser features such as camera or geolocation you don't use.
How to add them
Headers are set at the web server, CDN or application layer — an Nginx add_header block, an Apache Header set directive, a CDN rule, or middleware in your framework. Roll out Content-Security-Policy in report-only mode first; a strict policy can break inline scripts and third-party widgets.
This is a basic security check
Headers are one layer. They do not cover outdated software, weak credentials, vulnerable plugins, exposed admin panels or server hardening. Treat a passing result as one box ticked, not a complete security audit.
Frequently asked questions
- Can security headers break my site?
- A strict Content-Security-Policy can block legitimate scripts. Deploy it in report-only mode, review violations, then enforce. The other headers are low risk.
- Is X-XSS-Protection still needed?
- No. Modern browsers ignore it; Content-Security-Policy replaced it.