Content-Security-Policy

Pick a Content-Security-Policy (CSP) to see how it controls which scripts and styles are applied, and how Cross-Site Scripting vulnerabilities can be exploited.
STRICT (default)
  • Uses nonces to restrict which scripts may load
  • Safely inserts nonces value into HTML via templating
  • The burden is on the developer to handle templating properly
  • Most secure way to allow some scripts and styles, but least flexible
MODERATE
  • Automatically injects nonces into specified tags (script, style, link)
  • Good enough for most static web pages
  • Accepts the risk of injecting nonces into unwanted script, style, and/or link tags that were present in the page
  • Balances convenience with security
RELAXED
  • Uses 'unsafe-inline' for directives script-src, script-src-attr, style-src, and style-src-attr
  • Allows frame ancestors and embedded iframes
  • Suitable for applications that don't expose much risk
  • Favors convenience and flexibility over security
NO CSP
  • The browser won't enforce any restrictions on content (except for some builtin XSS mitigation features)

Current CSP:

If this is red, an inline style attribute was applied.
Can link href execute JS?

Cross-Site Scripting (XSS) Tests

Reflected XSS

Method #1

using setHTMLUnsafe

Try <img src=x onerror=alert(1)>

Method #2

using setHTMLUnsafe + document.write()

Try <script>alert('xss');</script>

Persistent XSS Tests

Assume users save free-form text to a content database, and this page loads that content into the DOM without output encoding or sanitization. What happens when that content contains an XSS Payload?

If this box is empty, the CSP is doing its job.

If not, we've been the victim of XSS

Escaped Dynamic Content

Unescaped Dynamic Content