Bug #92893
closed
SVG sprites are a breaking change, requiring CSP `default-src` to not be 'none'. Otherwise, icons are blocked in Firefox.
Added by Leonie Philine over 3 years ago.
Updated 16 days ago.
Category:
Backend User Interface
Description
Backend icons are broken in Firefox on sites with a good CSP policy, applying a strict `default-src: 'none'` and using granular controls for e.g. `script-src`, `img-src` etc.
Example of a TYPO3 backend CSP: (Yeah, we don't like unsafe-inline and unsafe-eval, either!)
Content-Security-Policy: default-src 'none'; font-src 'self'; img-src 'self' data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; style-src 'self' 'unsafe-inline'; frame-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; manifest-src 'self'
In Firefox, the SVG Sprite icons (introduced in a security patch version!) are not displayed, because `img-src` does not apply. See bugs:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1303364#c4
- https://github.com/w3c/webappsec-csp/issues/199
- https://github.com/w3c/webappsec-csp/issues/198
This should probably have been a "breaking change" for TYPO3 11, since admins / devops engineers will need to open up the CSP policy now.
Regression, please undo.
Implementation detail:
The new SVG sprites use xlink:href
- e.g.:
<use xlink:href="/typo3/sysext/core/Resources/Public/Icons/T3Icons/sprites/apps.svg#apps-pagetree-page-shortcut-external />
However, xlink:href
is deprecated:
- Related to Task #92689: Update @typo3/icons to v2 and support icon sprites added
Without having it tested... the only work-around for this seems to weaken default-src, but restrict remaining fetch directives.
Any token/hash based grant probably would not work with inline SVGs.
# Fetch directives
Content-Security-Policy: default-src 'self'; connect-src 'self'
Content-Security-Policy: font-src 'self'; img-src 'self' data:
Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'
Content-Security-Policy: style-src 'self' 'unsafe-inline'
Content-Security-Policy: frame-src 'self'; frame-ancestors 'self'
# note: media-src was missing, probably should be 'self' instead for a CMS
Content-Security-Policy: child-src 'none'; object-src 'none'; media-src 'none'
# W3C working draft directives
Content-Security-Policy: prefetch-src 'none'; worker-src 'none'
# Document & Navigate directives
Content-Security-Policy: base-uri 'self'; form-action 'self'; manifest-src 'self'
given policy in report
Content-Security-Policy:
default-src 'none'; connect-src 'self';
font-src 'self'; img-src 'self' data:;
script-src 'self' 'unsafe-inline' 'unsafe-eval';
style-src 'self' 'unsafe-inline';
frame-src 'self'; frame-ancestors 'self';
object-src 'none';
base-uri 'self'; form-action 'self'; manifest-src 'self'
- Related to Bug #95312: SVG Style-Tag CSP-Block / Firefox-Bug added
- Status changed from New to Needs Feedback
Tested the following CSP settings in a TYPO3 backend of version 11:
Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src-attr 'unsafe-inline'; style-src-elem 'self' 'unsafe-inline'; frame-src 'self'; child-src 'none'; object-src 'none'; prefetch-src 'none'; worker-src 'self' blob:;
Side notes:
script-src
unsafe-eval
was removed
unsafe-inline
is still kept due to CKEditor v4 doing inline magic (basically not using DOM operations, but using document.write
)
worker-src
blob:
allowed for muuri.js
which is used in the Dashboard view
default-src
- weakened from
none
to self
- adjusted
child-src
, object-src
and prefect-src
to keep none
There's still a lot of things to do for applying real secure CSP settings for the TYPO3 backend (the initially reported rules are not considered secure due to unsafe-eval
and unsafe-inline
). Please let me know whether the adjusted CSP above fits your needs for the time being. Thanks in advance!
- Tags changed from CSP to pending-close
Could not reproduce in TYPO3 v12.2-dev anymore...
- Status changed from Needs Feedback to Closed
- Target version deleted (
Candidate for patchlevel)
Sorry but I close this issue as it seems it affects only v.11 (which is in "Priority bugfix mode")
If you think that this is the wrong decision or experience the issue on more recent TYPO3 versions like 12 or 13 please open a new issue with a reference to this one.
Thank you and best regards
Also available in: Atom
PDF