Project

General

Profile

Actions

Feature #105087

open

CSP Header option to disable or reduce amount of reporting-uri requests

Added by Sascha Zander about 2 months ago. Updated about 1 month ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
Content Security Policy
Start date:
2024-09-23
Due date:
% Done:

0%

Estimated time:
PHP Version:
8.2
Tags:
csp
Complexity:
Sprint Focus:

Description

Hi,

I couldn't find a way to render the CSP headers without the reporting-uri.

The problem is that we have a lot of thirdparty javascripts on the page.
As soon as we have a new CSP error, our network load doubles every time due to the reporting request of the clients.

It would be better if the reporting-uri would only be attached for logged in backend users or to have an option to turn it off completely.

Actions #1

Updated by Chris Müller about 2 months ago · Edited

How gets that third-party code in? By a tag manager or other loader script which then loads additional code? Then a solution might be to use strict-dynamic:
https://content-security-policy.com/strict-dynamic/

Then the "root script" is always trusted and can load additional scripts from other domains without adjusting your policy.
Please also mind the fallbacks for browsers which does not support strict-dynamic currently (from the major browsers currently only Firefox on Android).

You might also use the PolicyMutatedEvent to adjust your policy:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/Events/Core/Security/PolicyMutatedEvent.html
This way, you can check the request and set the report-uri accordingly.

The amount of requests cannot be lowered directly, because the requests are send by the browsers. Indirectly with adjusting the report-uri endpoint, for example, by restricting the IP adresses (with the mentioned event).

Actions #2

Updated by Chris Müller about 2 months ago

  • Status changed from New to Needs Feedback
Actions #3

Updated by Sascha Zander about 2 months ago

Chris Müller wrote in #note-1:

How gets that third-party code in? By a tag manager or other loader script which then loads additional code? Then a solution might be to use strict-dynamic:
https://content-security-policy.com/strict-dynamic/

Then the "root script" is always trusted and can load additional scripts from other domains without adjusting your policy.
Please also mind the fallbacks for browsers which does not support strict-dynamic currently (from the major browsers currently only Firefox on Android).

I do not want to allow this, as we cannot trust the scripts well enough for security reasons.
There is a possibility that they could download harmful content in the future.

You might also use the PolicyMutatedEvent to adjust your policy:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/Events/Core/Security/PolicyMutatedEvent.html
This way, you can check the request and set the report-uri accordingly.

The amount of requests cannot be lowered directly, because the requests are send by the browsers. Indirectly with adjusting the report-uri endpoint, for example, by restricting the IP adresses (with the mentioned event).

How exactly can I use the PolicyMutatedEvent to restrict it to certain IP addresses?
When I try to remove the Directive::ReportUri, it is added again due to the code here:
https://github.com/TYPO3/typo3/blob/6b9220ed3f878e8c09f9e1dbb6e058eca8b664f3/typo3/sysext/backend/Classes/Middleware/ContentSecurityPolicyHeaders.php#L67

Actions #4

Updated by Garvin Hicking about 2 months ago

You might be able to 'abuse' setting the reportURI like this:

$GLOBALS['TYPO3_CONF_VARS']['BE']['contentSecurityPolicyReportingUrl']
        = 'abc:invalid';

$GLOBALS['TYPO3_CONF_VARS']['FE']['contentSecurityPolicyReportingUrl']
        = 'abc:invalid';

This should then return a `null` URI (InvalidArgumentException), which in turn would prevent adding a Report-URI.

(Having said that - might still be worth investigating if removing a report-uri could be made easier, as it's an optional argument [and actually deprecated, but report-for seems to not have been widely adopted yet])

Actions #5

Updated by Benni Mack about 1 month ago

  • Target version changed from 13 LTS to Candidate for Major Version
Actions

Also available in: Atom PDF