Currently, the CSP is missing a connect-src directive and several other important directives while restricting many data sources. As a result, the CSP is both overcomplicated and less secure than it could be. I think enough time has passed to try and do it in a more structured way. Sorry if this is already planned elsewhere, I'm not aware of any efforts to identify and remove scripts using eval() and similar.
| Directive | What it controls | Notes |
| connect-src | fetch, XHR, WebSocket, etc. | Should be relatively permissive; gadgets should be able to download data to enhance editing etc. A starting value could even be *. |
| script-src | loading and executing JS | Should be very restrictive. It should eventually be replaced by the more specific script-src-elem and script-src-attr directives. |
| → script-src-elem | loading and executing JS in script tags | Can replace script-src. It should eventually allow only trusted sources and should not include 'unsafe-inline' or 'unsafe-eval'. |
| → script-src-attr | event attributes (e.g. onclick) | Can replace script-src. It should eventually be set to 'none' (disabling event handlers in attributes while still allowing using addEventListener() etc). |
| style-src | loading and processing stylesheets | Should be fairly restrictive. Gadgets may still need to load fonts or external stylesheets, so the current value may be kept. |
Other things to consider (if not already considered):
- font-src *; (or more restrictive)
- image-src *; (or more restrictive)
- frame-src 'self'; (or more restrictive)
- X-Frame-Options: SAMEORIGIN or frame-ancestors 'self'
The rollout could proceed in the following stages.
Stage 1
Start with something like:
- connect-src *
- script-src-attr 'unsafe-inline'
- script-src-elem *current value*
- img-src * data:
- probably keep other rules (default-src, object-src, reporting)
In reporting rule, add checks for:
- script-src-attr: unsafe-inline.
- script-src-elem: unsafe-eval and unsafe-inline.
Stage 2
After gathering enough initial data, start discussing changes with the teams that add these patterns in core and extensions. Also discuss data with volunteer developers to update gadgets and possibly other tools.
Repeat when new data arrives. Perhaps monthly reviews.
End when no new data is reported and at least a few months have passed.
Stage 3
Remove execution gates when changes are deployed:
- script-src-attr: unsafe-inline.
- script-src-elem: unsafe-eval and unsafe-inline.
My guesstimate would be that unsafe-eval will be the easiest to eradicate. This is something old scripts might use, and it should be fairly easy to fix. In the wider JS ecosystem, eval is something that older libraries used, but I think most of them are not used on Wikimedia sites.
CSP rules graph
CSP rules have fallbacks, below graph should contain most of them. I think the image is from 2023, but nothing important for wikis was added recently. I mean I assume Trusted Types would be too complicated for wikis (not feasible).
