meta
element of the HTML page:eval()
.<script>
elements, but also things like inline script event handlers (such as onclick
) and XSLT stylesheets which can trigger script execution.default-src
:base-uri
form-action
frame-ancestors
plugin-types
report-uri
sandbox
<frame>
and <iframe>
.<a>
, fetch
, websocket
, XMLHttpRequest
.<frame>
and <iframe>
.<frame>
, <iframe>
, <object>
, <embed>
, and <applet>
tags. This directive can't be used in <meta>
tags and applies only to non-HTML resources.<audio>
, <video>
and <track>
can be loaded.<object>
, <embed>
and <applet>
elements.<base>
element.<form>
tags. Whether form-action
should block redirects after a form submission is debated and browser implementations of this aspect are inconsistent (e.g. Firefox 57 does not block the redirects whereas Chrome 63 does).<embed>
, <object>
or <applet>
elements will fail if:<iframe>
sandbox attribute. It applies restrictions to a page's actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy.data:
, blob:
and filesystem:
.data:
scheme (eg Base64 encoded images).eval()
and similar methods for creating code from strings.<script>
elements, javascript:
URLs, inline event handlers, and inline <style>
elements.website.com
:website.com
:attacker-website.com
:attacker-website.com
:img-src
is set to self
and follows default-src
by default.<iframe>
. The condition is that application should allow <iframe>
from the whitelisted domain. Using a special attribute srcdoc
of <iframe>
XSS can be easily achieved. Possible payload:<iframe>
(it fails most of the time in new browser due to SOP):%2f
to encode /
, it is still considered to be inside the directory. All browsers seem to agree on that. If a server decodes %2f
it is possible to bypass CSP by using '%2f..%2f'
. Possible payload:script-src
is set to self
and a particular domain is whitelisted it is possible to bypass this using JSONP. JSONP endpoints allow insecure callback methods that allow an attacker to perform XSS. Possible payload:script-src
is set to self
and a javascript library domain is whitelisted it is possible to bypass using any vulnerable version of javascript files from the library that allow you to perform XSS. Working payloads:unsafe-eval
. Possible payload:unsafe-inline
. Possible payload:default-src
, allowing use object-src
. Possible payloads:nonce
value is generated by a weak generator or its value can be guessed at, you can bypass a policy by generating the correct nonce
.script-src
. Possible payloads: