CSP base-uri directive on “View page source” on

Question

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?

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:

'self'

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.