Skip to content
ctfpal
All tools
WebRuns locallyNo account

HTTP security header analyzer

Analyse CSP, HSTS, X-Frame-Options, and CORS headers on a response - and find the gaps in a Content-Security-Policy that make XSS exploitable.

Open in ctfpal

In a CTF, security headers are read as a map of what the challenge expects you to do. A restrictive CSP means the intended XSS needs a bypass; a permissive CORS policy means cross-origin data theft is on the table.

CSP weaknesses worth spotting

  • unsafe-inline in script-src - inline scripts execute, so the CSP provides no XSS protection at all.
  • unsafe-eval - eval and Function work, which reopens most payload families.
  • A wildcard or overly broad host - if any path on an allowed CDN can serve attacker-controlled JavaScript, the policy is bypassed.
  • Missing object-src - <object> and <embed> fall back to default-src; if that is absent too, plugin content is unrestricted.
  • A JSONP endpoint on an allowed origin - the classic bypass, because JSONP turns any allowed host into an arbitrary-script source.

CORS misconfiguration is its own bug

Access-Control-Allow-Origin reflecting whatever Origin you send, combined with Access-Control-Allow-Credentials: true, means any site can read authenticated responses from this one. That pair is a finding in its own right, and it is what to check first when a challenge involves two origins.