Skip to content
CyberLens AI

Security guide

How to check your website's security headers for free

Published by CyberLens AI. Last updated .

Security headers are HTTP response fields that tell browsers how to handle your site's content. Missing headers leave your site open to clickjacking, content injection, and data leakage.

Here are three free methods to check yours in under two minutes: browser DevTools, an automated no-signup scan, and a single curl command.

Run a free header scan How to fix missing headers

Step 1: Browser DevTools

Press F12, open the Network tab, reload the page, click the first document request, and look under Response Headers. Check for Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.

  • Strict-Transport-Security — missing header allows protocol downgrade attacks
  • Content-Security-Policy — missing header allows XSS and content injection
  • X-Frame-Options — missing header enables clickjacking
  • X-Content-Type-Options — missing header enables MIME-sniffing attacks
  • Referrer-Policy — missing header leaks URLs to third parties
  • Permissions-Policy — missing header over-grants browser API access

Step 2: Free automated scan

CyberLens AI produces a letter grade, severity-ranked findings, and plain-English remediation steps. No signup required. Paste in your URL and scan.

  • TLS certificate validity and cipher suite posture
  • Cookie security flags (HttpOnly, Secure, SameSite)
  • Content-Security-Policy directive coverage
  • Cross-Origin Resource Policy and Opener Policy

Step 3: curl command-line check

Use curl -sI -L https://yourdomain.com to fetch response headers only. Pipe through grep for the six critical headers. Empty output means all six are absent — a common finding on freshly deployed sites.

  • curl -sI -L https://yourdomain.com | grep -i strict-transport-security
  • curl -sI -L https://yourdomain.com | grep -i content-security-policy
  • curl -sI -L https://yourdomain.com | grep -i x-frame-options
  • For CI pipelines, script the grep and fail the build on empty output

Step 4: Interpret your results

Once you have the raw headers, here is what each one controls and why its absence matters for your security posture.

  • Strict-Transport-Security: forces HTTPS, prevents protocol downgrade (set max-age=31536000)
  • Content-Security-Policy: restricts script/resource origins, primary XSS mitigation
  • X-Frame-Options: prevents clickjacking by blocking iframe embedding
  • X-Content-Type-Options: nosniff stops MIME-type guessing by browsers
  • Referrer-Policy: strict-origin-when-cross-origin limits URL leakage
  • Permissions-Policy: restrict camera, microphone, geolocation if unused

Step 5: Fix missing headers and re-scan

Add headers in vercel.json (headers array), Helmet middleware for Express/Node.js, or add_header directives in Nginx. Then re-run the scan to confirm the headers appear and the grade improves.

  • Vercel: add headers array to vercel.json
  • Express/Node.js: use helmet() middleware — configures all six in one call
  • Nginx: add add_header directives in the server block with always
  • Re-scan after deploy to confirm headers appear in response

Questions and answers

Which security header should I add first?

Start with X-Content-Type-Options: nosniff — it is a single line, universally supported, and has zero risk of breaking anything. Then add Strict-Transport-Security and X-Frame-Options. Leave Content-Security-Policy until last because a misconfigured CSP can break your page.

Does adding security headers break my site?

Most headers (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy) are low risk and rarely break anything. Content-Security-Policy is the exception — a strict CSP can block inline scripts, third-party fonts, or CDN assets you rely on. Use report-only mode first to audit violations before enforcing.

Will security headers affect my website performance?

No. Security headers are small strings sent in the HTTP response and have no measurable performance cost. They are evaluated by the browser before the page renders, not during it.

How often should I check my security headers?

Check after every deployment that touches your server configuration, CDN settings, or proxy layer. Also check after adding new third-party scripts, since those can conflict with an existing Content-Security-Policy. A scheduled monthly scan is a good baseline.

Do security headers protect against all web attacks?

No. Security headers reduce the browser-side attack surface — clickjacking, certain XSS vectors, MIME-sniffing, and protocol downgrade attacks. They do not protect against server-side vulnerabilities, SQL injection, authentication flaws, or misconfigured access controls. Use them alongside server hardening, dependency audits, and application-layer reviews.

Security references

CyberLens AI guidance is informed by established security standards and public vulnerability intelligence.