Project

General

Profile

Actions

Feature #105087

open

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

Added by Sascha Zander 4 months ago. Updated 3 months 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.


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Bug #105856: CSP reports may flood databaseUnder Review2024-12-20

Actions
Actions #1

Updated by Chris Müller 4 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 4 months ago

  • Status changed from New to Needs Feedback
Actions #3

Updated by Sascha Zander 4 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 4 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 3 months ago

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

Updated by Oliver Hader 28 days ago

  • Related to Bug #105856: CSP reports may flood database added
Actions

Also available in: Atom PDF