CSP

Si vous êtes familier avec les en-têtes de sécurité HTTP, vous avez peut-être déjà entendu parler des content security policies, sans jamais oser les implémenter pour ne pas risquer de bloquer des composants de votre site.

Je vous propose de voir de quoi il s’agit et comment les mettre en place, sans tout casser !

Principe des CSP

Les CSP font partie des en-têtes de sécurité à implémenter sur le serveur Web.

Ces politiques permettent de lister les ressources par catégorie afin d’évier qu’une ressource externe non prévue exécute du code sur votre site.

Il faut alors lister d’où sont censés venir les images, les styles, les scripts, …

Directives possibles

Directive Rôle
default-src Politique par défaut pour toutes les ressources.
script-src Politique pour les scripts JS
object-src Politique pour les plugins
style-src Politique pour les CSS
img-src Politique pour les images
media-src Politique pour les ressources vidéo ou audio
frame-src Politique pour les iframe embarqués dans la page
font-src Politique pour les polices de caractères
form-action Politique des actions que les formulaires peuvent appeler
sandbox Politique de “bac à sable” pour les ressources protégées
script-nonce Politique pour les scripts qui requièrent l’attribut ’nonce'
plugin-types Définit quel plugin peut être appelé
reflected-xss Activation/Désactivation des filtrage X-XSS
report-uri Définir une URI à laquelle envoyer les stats sur le fonctionnement des CSP

Politiques possibles

Politique Explication
“*” Autorise toutes les ressources (à éviter)
“none” Interdit ce type de ressources
“self” Autorise les ressources provenant du même sous-domaine que la page elle-même
“unsafe-inline” Pour JS et CSS : Autorise le code JS ou CSS directement dans le code source (à éviter)
“unsafe-eval” Pour JS : Autorise les mécanismes comme eval() (à éviter)
" https://ledomaine.source.com/laressource/" Autorise une URI en particulier
Wildcards, par exemples :
“https://*” " https://*" : Autorise toute ressources mais en HTTPS seulement (à éviter)
“https://ledomaine.com/” “https://ledomaine.com/” : Autorise toute ressource venant de ledomaine.com ou de ses sous-domaines (le plus précis sera le mieux).

Méthode de mise en place

  1. Lister les ressources appelées

a. On peut utiliser la console développeur Firefox/Chrome pour voir les requêtes GET et en déduire les appels b. On peut regarder le code source de la page c. Lister les ressources

  1. Créer les règles CSP adaptées (exemple)
Ressource Origine Règle CSP
Image Balise dans le code HTML img-src: ‘self’
Image Image dans le code CSS provenant du site lui-même img-src: ‘self’
CSS Styles venant d’un CDN style-src: ’ https://maxcdn.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css' ou bien : style-src: ‘https://maxcdn.bootstrapcdn.com/bootstrap/*/css/bootstrap.min.css’
CSS Intégré au code source (balise style) style-src: ‘unsafe-inline’
CSS Depuis le même domaine style-src: ‘self’
JS Scripts venant d’un CDN script-src: ‘https://ajax.googleapis.com/ajax/libs/jquery/* '
JS Depuis le même domaine script-src: ‘self’
… … …
  1. Exemple de règles qu’on obtient :
Content-Security-Policy: default-src 'self'; style-src: 'https://maxcdn.bootstrapcdn.com/bootstrap/*/css
/bootstrap.min.css' 'unsafe-inline' 'self'; script-src 'https://ajax.googleapis.com/ajax/libs/jquery/*'
'self';

Cette règle s’ajoute sur le serveur Web sous cette forme :

Header always set content-security-policy "default-src 'self';"
  1. Ajouter une règle report-to :
Content-Security-Policy-Report-Only: report-uri /csp-violation-report-endpoint/
  1. Créer un compte sur Report-uri.io
  2. Les mettre en place en Dev ou Valid
  3. Vérifier avec report-uri.io si les règles sont correctes
  4. Les passer en Valid et en Prod

Ressources