I'm assessing the security level of a webapp and one of the test cases is the CSP header. I always use the Google CSP evaluator to assess the header. Let's consider the following CSP header:

img-src 'self' https://example.com data: www.google-analytics.com;  
object-src 'self' https://example.com data:; 
script-src 'self' https://example.com www.google-analytics.com;

The evaluator states that there are two high severity findings; one for allowing the data attribute for an object element; other one for missing the base-uri directive. So I thought: "Hey, that's great, then maybe we can still exploit XSS by bypassing the CSP."

However, in my local webserver set-up with the CSP header above, the CSP policy still triggers a violation when injecting object elements with a data attribute or a base element. I'm rendering a page which echoes the user input from a query string right into the page unescaped.

I've read some articles about people succeeding in bypassing CSP with object elements and base-uri's like these:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
<base href="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==" />


Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

The CSP policy blocks these payloads as it states that inline scripts are not allowed. Even with a barebone CSP like default-src 'self' the violation still triggers.

  1. Has something changed over time or am I just doing it wrong?
  2. Are data attributes URI's etc. always seen as inline scripts?
  3. How 'high' are these findings then? Only setting 'unsafe-inline' will make the bypasses work, but that completely makes the bypass useless, because then you can inject script tags whatsoever.


You must log in to answer this question.

Browse other questions tagged .