Closed hmeneuvrier closed 4 months ago
TODO :
[x] enlever 'unsafe-eval
' de script-src --> pas possible car on utilise eval()
dans le formulaire pour les conditions
[ ] enlever 'unsafe-inline
' de script-src --> possible, soit en externalisant tous les scripts js dans des fichiers séparés (y compris dans VueJS), soit en utilisant des nonces dans les balises scripts, soit en configurant webpacks pour s'assurer que je js est dans des fichiers séparés.
<script nonce="random123">...</script>
script-src 'self' 'nonce-random123';
[ ] Pareil pour les balises de style, enlever le unsafe-inline
[x] Ne pas pointer vers les domaines entiers de jsdelivr
et matomo
, mais vers les spécificités dont on a besoin (éventuellement aussi utiliser des nonces)
[x] Évitez l'utilisation de data:
et blob:
autant que possible --> trop compliqué, et pas demandé par mozilla observatory
[x] Ajouter la directive pour les plugins : plugin-types
--> on n'utilise pas des balises <object>
, <embed>
, ou <applet>
., donc pas besoin
[x] Ajouter la directive base-uri
--> ajouter base-uri 'self'
et vérifier que tinymce marche toujours
[x] Ajouter la directive form-action
--> ajouter form-action 'self'; puisque toutes les actions de formulaires sont destinées à notre propre domaine
[x] Ajouter la directive frame-ancestors
--> ajouter frame-ancestors 'none';
car aucun autre site n'a besoin d'intégrer histologe en frame ou en iframe
[x] Ajouter la directive manifest-src
--> pas besoin car pas de fichier manifest
[x] Ajouter la directive media-src
--> ajouter media-src 'self'; (mais vérifier si on utilise audio ou video, je n'ai pas l'impression)
[x] Deny by default, using default-src 'none'
--> mettre default-src 'none';
au lieu de default-src 'self';
puisqu'on autorise ensuite, et faire un tour sur tout le site pour faire de la TNR
On a cette alerte quand on build le projet RECOMMEND To create a smaller (and CSP-compliant) build, see https://symfony.com/doc/current/frontend/encore/vuejs.html#runtime-compiler-build
C'était un peu le sens de ma remarque lors de la retro :)
default-src 'none';
--> empêche le chargement des svg contenus dans le dsfr malgré l'utilisation de img-src 'self'
... je cherche une solution
-> ça marche sous Chromium mais pas sous Firefox. Solution possible : https://discourse.mozilla.org/t/content-security-policy-for-svg-use/95310
bon c'est chaud de retirer unsafe-unline pour style src, car il faut vraiment TOUT mettre dans des trucs externes
Et j'ai des soucis avec le profiler de symfony malgré Made the toolbar compatible with Content Security Policy et malgré une mise à jour de symfony cli car il y a eu une correction dans la version 5.8.13 Romain Neutron
Contributed by Romain Neutron in #18568.
The new Content Security Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header.
If your application defines such a policy, the script-src or style-src directives could disallow unsafe inlines, which would prevent the loading of the web debug toolbar.
In Symfony 3.2 we made the web debug toolbar compatible with those kind of Content Security Policies. Internally this change required massive code updates, but for developers it will be completely transparent and it won't require any change in their applications.
Pour le style, j'arrive à simplifier un peu les choses en ajoutant style-src-attr 'self' 'unsafe-inline';
Utilisation de Nelmio Security Bundle en dernier recours.
Essayer de faire un ContentSecurityPolicyListener pour intercepter les nonces de la toolbar et générer des nonces aléatoirement pour les Githubissues.
https://observatory.mozilla.org/analyze/histologe.beta.gouv.fr
Content Security Policy
-20 Content Security Policy (CSP) implemented unsafely.
This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src.