Content Security Policy (CSP)

Ce qu'une politique contrôle vraiment

Une politique est une liste de directives, chacune régissant un type de requête. Elle a été conçue comme une seconde ligne de défense contre le cross-site scripting : si un attaquant parvient à injecter du balisage dans votre page, le navigateur refuse malgré tout d'exécuter un script provenant d'une source que la politique n'a jamais nommée. Les directives que vous croiserez en premier :

• default-src — la valeur de repli. Tout type de requête sans directive propre hérite de celle-ci, si bien que default-src 'self' couvre discrètement les polices, les médias et le reste, sauf indication contraire.
• script-src, style-src, img-src, font-src — d'où peut provenir chaque type de sous-ressource. 'self' désigne l'origine de la page elle-même ; un nom d'hôte autorise cet hôte ; 'unsafe-inline' autorise le code écrit directement dans la page.
• connect-src — vers où le code de la page peut envoyer des requêtes via fetch, XHR ou WebSockets. C'est la directive qui décide si un script peut contacter un serveur extérieur.
• form-action — vers où un formulaire peut être envoyé. frame-ancestors — qui peut intégrer la page dans un cadre, le remplaçant moderne de X-Frame-Options.
• Nonces et hashes — un moyen d'autoriser un script inline précis sans les autoriser tous : le serveur marque le script qu'il a écrit, et tout ce qui est injecté plus tard ne porte pas cette marque.

Deux détails de mise en place piègent souvent. Une politique peut aussi être définie dans une balise <meta http-equiv>, mais cette forme ne prend pas en charge toutes les fonctionnalités, et une politique en mode rapport seul ne peut pas du tout être transmise ainsi. Et si une politique répète la même directive, le navigateur applique la première et ignore la seconde : une règle « ajoutée » peut ainsi ne rien faire tout en paraissant correcte dans le code source.

Pourquoi une ressource bloquée échoue en silence

Quand le navigateur refuse une requête au nom d'une politique, il écrit une ligne dans la console de développement et poursuit l'affichage. Pas de page d'erreur, pas d'alerte, rien qu'un visiteur ou un propriétaire jetant un œil au site remarquerait. L'allure de la page dépend alors entièrement de ce qui a été refusé. Un script d'analyse bloqué laisse la page identique au pixel près et vos chiffres à zéro. Une police web bloquée se rabat sur une police système que la plupart des gens ne remarquent jamais. Une feuille de style ou un framework CSS bloqué transforme une page soignée en HTML brut sans mise en forme.

C'est cet écart qui pose problème en pratique : le même type de violation va de l'invisible à la page détruite, et le texte de la politique ne vous dit pas de quel côté vous êtes. Testez l'URL déployée, pas une copie locale — un fichier ouvert depuis votre ordinateur est en général servi sans aucune politique, il peut donc charger tout ce que la page en ligne refusera. C'est la raison la plus courante pour laquelle une page construite avec l'IA paraît correcte en aperçu et fausse une fois publiée.

Ce que nous a appris l'hébergement des pages d'autres personnes

AgentCeres — l'AI Growth Officer sur agentceres.com — publie les pages que ses agents construisent pour les clients, et chacune est servie sous une politique stricte : ressources uniquement depuis l'origine de la page, images depuis l'origine ou intégrées directement, formulaires qui ne s'envoient qu'à l'hôte, aucune intégration dans d'autres sites, et connect-src 'none', de sorte que le code de la page peut calculer, mémoriser des choses localement et naviguer, mais ne peut pas émettre la moindre requête réseau. Cette dernière règle explique pourquoi un secret placé dans le code de la page ne peut même pas être utilisé depuis la page en ligne.

Lorsque nous avons vérifié toutes les pages hébergées le 2026-09-04, 5 sur 52 contenaient au moins une ressource externe qui ne s'était jamais chargée. Le pire cas était une page dont toute la mise en page venait d'un framework CSS chargé depuis un CDN public ; la politique ne nomme aucun hôte extérieur, le framework n'est donc jamais arrivé et la page a été mise en ligne en simple texte sans mise en forme. D'autres ont perdu un flux radio ou un cadre intégré. Nous avons envisagé de retirer les références bloquées au moment de la publication, puis y avons renoncé, car une page ainsi nettoyée « se publie sans problème » et reste fausse ; refuser purement et simplement ne valait pas mieux, puisque la même règle bloquerait une page pour une police qui se contente de se rabattre sur une autre. L'étape de publication signale donc chaque référence bloquée avec la directive qui la refusera, et la correction a lieu avant que quiconque voie la page. Le verdict est calculé à partir de la même liste de directives que celle envoyée par le serveur, valeurs de repli comprises, afin que l'avertissement ne puisse pas s'écarter de la politique.

La leçon vaut au-delà de notre configuration : une politique que vous ne confrontez pas à de vraies pages est une politique qui casse des pages sans vous prévenir. Avant de l'appliquer, envoyez-la en Content-Security-Policy-Report-Only, qui signale les violations sans rien bloquer, et lisez ce qu'elle aurait cassé.

Ce qu'une politique ne peut pas faire

La CSP régit ce qu'une page peut charger et vers où elle peut se connecter. Il est facile de lui prêter davantage.

• Elle n'a aucune directive pour les cookies. Un script autorisé par la politique peut toujours lire et définir des cookies, sauf ceux marqués HttpOnly. Des pages qui partagent un domaine parent peuvent aussi partager des cookies, et fermer cette porte demande un contrôle distinct, pas une politique plus stricte.
• Elle ne rend pas le code inline sûr. Autoriser 'unsafe-inline' permet tout ce qui est écrit dans la page, y compris ce qu'un attaquant a réussi à y écrire ; c'est précisément ce que les nonces et hashes permettent d'éviter.
• Elle ne remplace ni l'échappement ni la validation. Elle limite les dégâts d'une injection ; elle ne l'empêche pas. Une page qui fait confiance aux saisies des utilisateurs reste défaillante, simplement moins exploitable.
• Elle ne protège pas un agent IA de ce qu'il lit. Une politique empêche un navigateur de charger un script hostile ; elle ne fait rien contre un *texte* hostile qu'un agent lit et sur lequel il agit, ce qui relève du problème distinct de l'injection de prompt.