-
Notifications
You must be signed in to change notification settings - Fork 110
Description
I would like to propose the addition of support for the report-to directive by adding a new header Reporting-Endpoints in addition to the Content-Security-Policy header.
The report-to CSP directive is already supported but will only work in combination with the Reporting-Endpoints header. Current support leaves defining this header up to the end user.
Configuration Example:
CONTENT_SECURITY_POLICY = {
"REPORTING_ENDPOINTS": {
"csp-endpoint": "https://example.com/csp-reports",
"hpkp-endpoint": "https://example.com/hpkp-reports",
},
"DIRECTIVES": {
...,
"report-to": "csp-endpoint",
# For older browsers or those not yet supporting `report-to`.
"report-uri": "https://example.com/csp-reports",
}
}This would output the following HTTP headers:
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports",
hpkp-endpoint="https://example.com/hpkp-reports"
Content-Security-Policy: ...; report-to csp-endpoint
Notes:
Reporting-Endpoints
TheReporting-Endpointsheader is a newer, simpler alternative to theReport-Toheader. It directly maps names to reporting endpoints without the additional configuration options provided byReport-To. See: browser supportReport-To
TheReport-Toheader is used to define a group of reporting endpoints and the conditions under which reports should be sent to those endpoints. It is now a deprecated and non-standard feature: MDN: Report-To header
Arguments Against
There could be arguments made that this is beyond the scope of django-csp since, as shown in the above example, the reporting endpoints can also define other endpoints, such as the HTTP Public Key Pinning (HPKP) endpoints.
With this consideration, making this optional would be the best path forward. If Reporting-Endpoints is defined in some other way, the CSP headers could still reference the endpoints. If they aren't defined elsewhere, django-csp would add them if set.