I am in the process of implementing a CSP header for a webapp, with the goal of reducing possible XSS attacks. See CSP for an overview of CSP. I provided the base-uri directive as 'self' and this works as expected with violations being reported to the report-uri. See base-uri for an explanation of the base-uri directive.

What is surprising to me is that when I use chrome (Version 56.0.2924.87 64-bit) to "View page source" there is a CSP violation report. Here is an example of the violation report:

"csp-report": {
    "document-uri": "http://localhost:8080/frontend/Page1.action?param1=1",
    "referrer": "",
    "violated-directive": "base-uri",
    "effective-directive": "base-uri",
    "original-policy": "base-uri 'self'; report-uri /frontend/CspReport.action?",
    "disposition": "report",
    "blocked-uri": "http://localhost:8080/frontend/",
    "status-code": 200

I simplified the policy to make sure nothing else is interfering. From what I understand the "blocked-uri" should match the 'self' keyword because it matches the beginning of the "document-uri".

What makes this more strange is that it only happens when viewing source on some pages (but on these pages it happens 100% of the time) and does not seem to happen on firefox at all and does not happen when simply navigating between pages.

So, the question is why is this a CSP violation when it seems to not violate the specified directive?

  • This bug report gives some information as to why view-source is a separate scheme.
    – Sjoerd
    Mar 8, 2017 at 12:16
  • Thank you for the response Sjoerd. So, this means there was a violation because view-source:localhost:8080/frontend was a separate scheme than 'self' ( localhost:8080/frontend )? I guess this makes sense, but why did the "blocked-uri" not say view-source:localhost:8080/frontend ?
    – Andrew
    Mar 8, 2017 at 13:03
  • the csp code might not be aware of view-source's functionality and/or position in the pipeline; the url might have been "translated" by the time it reached the CSP. Since there's no way to run active content on view-source, it should not present much risk.
    – dandavis
    Mar 9, 2017 at 22:27
  • Thank you for the comments. I think these 2 points together answer my question. If one of you posts and answer I will mark it as the accepted answer. Otherwise on Monday, I will put a summary in an answer to close the question.
    – Andrew
    Mar 10, 2017 at 12:55
  • @dandavis congratulations on reputation = "404" :)
    – Andrew
    Mar 10, 2017 at 12:56

1 Answer 1


To help future users I will summarize the help information provided in the comments by @Sjoerd and @dandavis .

In the CSP specification 'self' is defined as follows:


Refers to the origin from which the protected document is being served, including the same URL scheme and port number. You must include the single quotes. Some browsers specifically exclude blob and filesystem from source directives. Sites needing to allow these content types can specify them using the Data attribute.

This is partially ambiguous as it seems scheme is not defined. In the example provided, Chrome defines the scheme of self to be http: and view-source:http: as a different scheme.

Firefox seems to have chosen a different interpretation where view-source:http: is the same scheme as http: or at least that they both match 'self' in the base-uri policy.

In chrome, you would expect the CSP report to contain

"blocked-uri": "view-source:http://localhost:8080/frontend/"

Which would hint about why the uri was blocked, but it looks like the view-source: part is removed before sending the CSP report.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .