21. CSP : politique de chargement et déploiement progressif

Comprendre le mécanisme

Content Security Policy restreint des sources et comportements du document selon ses directives. Une politique de script peut réduire les conséquences de certaines injections, sans corriger tous les défauts de rendu ni supprimer l’autorisation serveur. default-src fournit une valeur de repli pour certaines directives de chargement, mais pas pour toutes les directives. Une politique doit donc être lue dans son ensemble plutôt qu’assimilée à un mot-clé magique.

Raisonner et vérifier

Commencez par l’inventaire des ressources et des scripts réellement nécessaires. Le mode Report-Only permet d’observer des violations sans promettre un blocage. Réduisez les exceptions, vérifiez les parcours dynamiques puis activez une politique imposée. Les rapports peuvent révéler des URL ou des fragments de contexte : définissez collecte, minimisation et accès au lieu d’envoyer aveuglément ces données vers un tiers.

Observer avant bloquer

Report-Only observe une politique sans la bloquer. L’observation permet un déploiement progressif mais ne constitue pas le blocage. Report-Only produit une observation des violations selon ce mode sans imposer le blocage correspondant. Utilisez-le pour préparer une politique, puis vérifiez séparément la politique d’application effectivement envoyée.

Ressources nécessaires

Une CSP doit correspondre aux ressources nécessaires. Les dépendances et contextes du site doivent être inventoriés. Inventoriez scripts, styles, images et connexions réellement utilisés. Une politique trop large perd son intérêt ; une politique trop stricte non testée peut casser connexion, paiement ou affichage des erreurs.

Génération du nonce

Le nonce doit provenir d’une génération maîtrisée. Le serveur doit garder la maîtrise de la valeur admise. Le nonce doit venir d’un hasard cryptographique et suivre la réponse concernée. Une valeur fixe ou issue d’un timestamp permettrait de prévoir la capacité d’exécution que la politique essaie de limiter.

Encodage conservé

Une CSP ne remplace pas l’échappement contextuel. Les points de sortie doivent rester contrôlés. La CSP ne transforme pas une concaténation HTML dangereuse en donnée sûre. Corrigez les points d’injection et le contexte de sortie même lorsqu’un script de démonstration semble bloqué par le navigateur.

Pages d’erreur

Les pages d’erreur peuvent nécessiter leur propre vérification. Les réponses et ressources peuvent différer selon le parcours. Une erreur peut passer par un autre template ou un autre composant. Vérifiez ses headers et ressources aussi, afin que le chemin dégradé ne perde pas la politique de la page nominale.

Rapports minimisés

Les rapports peuvent contenir des données à minimiser. Le diagnostic peut contenir des URL ou informations sensibles. Les rapports de violation peuvent exposer des URL ou fragments de contexte. Limitez collecte, accès et conservation ; le canal de diagnostic doit être traité comme un traitement de données propre.

Directives distinctes

Des directives ont des rôles différents. Les directives ciblent des catégories différentes. script-src, connect-src et frame-ancestors ne contrôlent pas les mêmes capacités. Expliquez chaque choix et ses règles de repli ; default-src n’est pas une réponse universelle à toutes les directives.

Politique reçue

Une politique effective doit être observée dans la réponse. Le trajet final et ses intermédiaires comptent. Inspectez les headers après passage par les proxies et les éventuelles politiques multiples. Une ligne dans le code source de configuration ne prouve pas le résultat effectivement interprété par le client.

Inline

Les ressources inline demandent une politique adaptée. Sa position dans la page ne suffit pas à établir son origine. Les scripts inline demandent une admission précise, par exemple nonce ou hash selon le cas. Évitez d’ajouter unsafe-inline pour résoudre une panne sans comprendre la capacité plus large ainsi réintroduite.

Retrait d’exception

Le retrait d’une exception doit être testé. Élargir une liste de sources peut affaiblir la restriction. Après suppression d’une origine admise, testez la fonctionnalité légitime et le refus du chargement retiré. Une politique peut sembler renforcée tout en laissant un autre chemin équivalent autorisé.

Atelier guidé : lire, expliquer et vérifier le code

Content-Security-Policy-Report-Only: script-src 'self'

Le navigateur observe un script qui violerait cette politique.

La réponse contient seulement une politique Report-Only et le navigateur observe une violation potentielle. Ne concluez pas que le script a été bloqué par cette politique. Comparez observation et application dans un laboratoire, puis vérifiez que le parcours nominal continue de fonctionner sous la politique appliquée.

Le mode d’observation ne fournit pas le blocage de la politique. C’est la distinction de ce mode. Le nom complet et son mode comptent. Un diagnostic ne modifie pas les points d’injection.

Travail pratique : Inventoriez les ressources d’une page de laboratoire, déployez une politique d’observation puis une politique bloquante minimale compatible.

Critères de correction : Testez chargement normal, module JavaScript, téléchargement et ressource refusée. Distinguez rapport reçu et blocage effectif. Retirez les permissions non justifiées et vérifiez que les rapports ne contiennent pas de secrets métier.