3

I was implementing a CSP policy and set up the reporting endpoint as another domain, a completely separate origin. Everything seemed to work fine, but talking to a few friends they seemed surprised that it worked as they thought that CSP reports could only go to the same domain or a subdomain. I looked around online and read through the spec but didn't find anything that substantiated their theory that it used to be that way.

I'm cautious going forward because I'd rather set up a reporting endpoint that I could get consistently rather than one that might fail on older browsers. Is there any truth to their suspicions that cross-origin reporting used to not be supported?

Thanks in advance :)

1

Having tested this at scale with a wide variety of browsers there does not seem to be any issue with the reporting endpoint being on a different domain.

1

Throughout all versions of CSP (v1, v2 current, v3) there has been no limitation on where the reports can be sent by the browser. The report-uri directive expects a URL, the following is taken directly from the spec:

The report-uri directive specifies a URL to which the user agent sends reports about policy violation.


Historically browsers would not send a CORS pre-flight for the reports, which technically put them in violation of the SOP, but modern versions of Chrome now pre-flight a CSP report. This means you need to answer OPTIONS requests with the appropriate ACAO headers if you want the browser to send reports.

1

Given that there are businesses centered around collecting these reports (e.g. the eponymous report-uri.com), it's obvious there are no limitation on the origin.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.