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

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

Politiques possibles

PolitiqueExplication
‘*’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

  2. Créer les règles CSP adaptées (exemple)

    RessourceOrigineRègle CSP
    ImageBalise dans le code HTMLimg-src: ‘self’
    ImageImage dans le code CSS provenant du site lui-mêmeimg-src: ‘self’
    CSSStyles venant d’un CDNstyle-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’
    CSSIntégré au code source (…)style-src: ‘unsafe-inline’
    CSSDepuis le même domainestyle-src: ‘self’
    JSScripts venant d’un CDNscript-src: ‘https://ajax.googleapis.com/ajax/libs/jquery/* '
    JSDepuis le même domainescript-src: ‘self’
  3. 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