Published: Tue 06 August 2024
By Yaakov Saxon
In Curiousities .
I recently was trying to improve the CSP headers on an application, so I get it set up running over http on localhost. I noticed very strangely that the policy itself worked fine, and reports were sent when I only included the older report-uri field. But if I included the newer report-to field in the CSP header, then although the CSP violations continued to be noted in the browser console, they were not sent to the reporting endpoint.
It turns out that the HTTP is the problem.
CSP headers are supported over HTTP (which is why the policy itself works) as are both the report-uri and report-to syntaxes, but the newer headers that define report-to endpoints are NOT supported under HTTP.
A browser that supports the newer report-to syntax will always use that in preference to the older report-uri syntax
It only falls back to report-uri if there is no report-to specified (or if the browser doesn't support report-to)
If report-to is specified and supported, but the endpoint group is not defined, the report will simply fail
The headers that define the report-to endpoint groups (there are actually two, the never fully implemented and now deprecated Report-To, and the even newer Reporting-Endpoints) are only parsed over HTTPS
So the browser will see the report-to specification and decide to send to an endpoint group by that name, but that endpoint group will not be defined, and the report will fail
You can see this in Chrome by going to DevTools -> Application -> Reporting API. You will see no endpoint groups defined if you are running over HTTP, and the report will stay listed as queued.
(Note that the Endpoints list does not seem to populate with the Report-To header, only the Reporting-Endpoints header even over HTTPS, but even with Report-To you will see that the report is eventually sent if you are running over HTTPS)
Proudly powered by Pelican , which takes great advantage of Python .
The theme is by Smashing Magazine , thanks!