Qu'est-ce qu'une Content Security Policy (CSP) ?

La Content Security Policy est un en-tête de réponse HTTP par lequel un site déclare au navigateur les sources de contenu qu'il autorise : scripts, styles, images, connexions réseau. Tout ce qui n'est pas explicitement autorisé est bloqué par le navigateur. C'est une défense en profondeur contre les injections de code, notamment les attaques XSS.

Une CSP peut-elle casser mon site en production ?

Oui, si elle est déployée d'un coup en mode bloquant. C'est précisément pour cela que le mode Content-Security-Policy-Report-Only existe : le navigateur applique la politique en observation, remonte les violations sans rien bloquer. On corrige les faux positifs à partir de ces rapports, puis on bascule en mode bloquant une fois le trafic réel silencieux.

La CSP remplace-t-elle un audit de sécurité ?

Non. La CSP est une mesure de défense en profondeur : elle limite l'impact d'une faille d'injection, elle ne l'empêche pas d'exister. Elle complète, sans les remplacer, la validation des entrées côté serveur, l'échappement des sorties, la gestion des dépendances et l'audit régulier de l'infrastructure.

Content Security Policy : Blindez Votre Site Next.js Contre les XSS

Qu'est-ce qu'une Content Security Policy ?

La Content Security Policy (CSP) est un en-tête de réponse HTTP par lequel votre serveur déclare au navigateur quelles sources de contenu sont légitimes : quels scripts peuvent s'exécuter, depuis quels domaines les images peuvent être chargées, vers quelles API le navigateur peut ouvrir une connexion. Tout ce qui n'est pas explicitement autorisé est bloqué, côté client, avant même de s'exécuter.

L'intérêt est direct : si un attaquant parvient à injecter du JavaScript dans une de vos pages — via un champ de formulaire mal filtré, un paramètre d'URL réfléchi ou une dépendance compromise — une CSP correctement configurée empêche ce code de s'exécuter. Les injections restent la première famille de vulnérabilités du Top 10 de l'OWASP, et les attaques XSS (Cross-Site Scripting) en constituent le vecteur le plus courant sur le web.

Pourquoi une PME est directement concernée

L'argument « nous sommes trop petits pour être ciblés » ne résiste pas à la réalité du terrain : l'immense majorité des attaques web sont automatisées et opportunistes. Les robots scannent des plages d'adresses entières à la recherche de formulaires vulnérables, sans se soucier du chiffre d'affaires de l'entreprise.

L'enjeu est aussi réglementaire. Un XSS exploité sur une page contenant des données clients — un espace de connexion, un tunnel de commande, un formulaire de devis — constitue une violation de données personnelles. Le RGPD impose alors, à son article 33, une notification à la CNIL dans un délai de 72 heures après en avoir pris connaissance. Une CSP ne dispense d'aucune obligation, mais elle réduit significativement la probabilité qu'un tel incident survienne.

Les directives à connaître

Une CSP se compose de directives, chacune gouvernant un type de ressource.

Les directives de contenu

default-src : la valeur de repli pour toutes les directives non précisées. Commencez par 'self', qui n'autorise que votre propre domaine.
script-src : la directive critique, celle qui bloque réellement les XSS.
style-src, img-src, font-src : feuilles de style, images et polices.
connect-src : les destinations autorisées pour fetch, XHR et WebSocket — souvent oubliée, elle casse les appels API si mal renseignée.

Les directives de durcissement

frame-ancestors : contrôle qui peut inclure votre site dans une iframe. Elle remplace l'ancien en-tête X-Frame-Options et protège contre le clickjacking.
base-uri : empêche un attaquant de réécrire la balise <base> pour détourner vos URLs relatives.
form-action : restreint les destinations vers lesquelles vos formulaires peuvent poster.

Deux valeurs sont à traiter avec méfiance : 'unsafe-inline' et 'unsafe-eval'. Elles vident script-src d'une grande partie de sa substance, puisqu'elles réautorisent précisément ce qu'un XSS exploite. Une CSP qui les contient sur script-src offre surtout une fausse impression de sécurité.

Nonce plutôt qu'allowlist

L'approche historique consistait à lister les domaines de confiance. Elle a montré ses limites : de nombreux domaines populaires hébergent des fichiers permettant de contourner la politique, et la liste devient vite ingérable.

L'approche recommandée aujourd'hui repose sur un nonce : un jeton aléatoire, régénéré à chaque réponse, inséré à la fois dans l'en-tête CSP et dans les balises <script> légitimes. Un script injecté par un attaquant ne peut pas deviner cette valeur, et le navigateur le rejette. Associée à 'strict-dynamic', cette méthode permet aux scripts de confiance de charger leurs propres dépendances sans réécrire toute la politique.

Sur Next.js, le nonce se génère dans le middleware, qui pose l'en-tête pour chaque requête ; le framework l'applique ensuite automatiquement à ses propres scripts. Un point d'architecture mérite d'être anticipé : comme le nonce change à chaque requête, les pages concernées basculent en rendu dynamique et sortent du rendu statique. Sur un site où la performance prime, cet arbitrage entre sécurité et mise en cache doit être décidé page par page, pas subi.

Déployer sans casser la production

Une CSP se déploie en trois temps, jamais d'un bloc.

Observation. Publiez la politique via l'en-tête Content-Security-Policy-Report-Only. Le navigateur signale les violations sans rien bloquer : votre site fonctionne normalement pendant que vous collectez des données réelles.
Correction. Les premiers rapports remontent presque toujours des faux positifs légitimes : outil d'analytics, service de chat, iframe de paiement, polices externes. Chacun se traite en ajoutant la source exacte à la bonne directive — jamais en élargissant default-src.
Bascule. Une fois le flux de rapports silencieux sur plusieurs jours de trafic représentatif, passez en Content-Security-Policy. Conservez un endpoint de rapport actif : il devient votre système d'alerte sur les régressions.

Sauter l'étape d'observation est l'erreur classique. Elle se solde par un tunnel de commande cassé un vendredi soir, et par une CSP désactivée en urgence — donc par aucune protection du tout.

Passez à l'action

Une CSP bien conçue est l'une des mesures de sécurité au meilleur rapport effort/bénéfice pour un site vitrine ou e-commerce : quelques heures de configuration, une protection durable contre toute une classe d'attaques.

Securium Agency conçoit et déploie des politiques de sécurité sur-mesure pour les sites Next.js, du mode observation jusqu'à la bascule en production, sans interruption de service. Nous auditons également votre configuration existante si vous avez déjà une CSP et souhaitez vérifier qu'elle protège réellement. Demandez votre audit de sécurité gratuit : nous vous remettons un diagnostic clair et un plan d'action priorisé.