-
Notifications
You must be signed in to change notification settings - Fork 108
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-Endpoints
header is a newer, simpler alternative to theReport-To
header. It directly maps names to reporting endpoints without the additional configuration options provided byReport-To
. See: browser supportReport-To
TheReport-To
header 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.