Un CSP nonce est une valeur aléatoire unique générée à chaque chargement de page qui permet de valider les scripts en ligne légitimes dans le cadre d'une politique de sécurité du contenu. En ajoutant ce nonce à la fois à l'en-tête CSP et aux balises de script autorisées, les développeurs peuvent autoriser des scripts en ligne spécifiques tout en conservant des protections XSS solides. Cette approche est particulièrement utile lorsqu'il est nécessaire d'insérer des scripts dynamiques, mais qu'une CSP stricte est souhaitée.
Un nonce CSP (« number used once », nombre utilisé une seule fois) est un jeton aléatoire et impossible à deviner que le serveur génère à chaque réponse et place à deux endroits : la source nonce-... dans l'en-tête Content-Security-Policy et un attribut nonce correspondant sur chaque balise <script> ou <style> inline qu'il souhaite autoriser. Le navigateur n'exécute un script inline que lorsque son attribut nonce correspond à la valeur déclarée dans l'en-tête pour ce chargement de page précis. Comme le jeton est régénéré à chaque requête et reste imprévisible, le balisage qu'un attaquant injecte ensuite ne peut porter un nonce valide, si bien que le navigateur refuse de l'exécuter. Cela permet à un site de conserver les scripts inline dont il a réellement besoin tout en abandonnant l'autorisation générale unsafe-inline sur laquelle repose le XSS.
La plupart des défenses contre le XSS s'effondrent dès qu'une politique doit autoriser unsafe-inline, car ce mot-clé indique au navigateur de faire confiance à chaque script inline, y compris ceux qu'un attaquant parvient à injecter. Une politique fondée sur les nonces supprime ce mot-clé : seul le code inline que le serveur a délibérément marqué avec le jeton courant peut s'exécuter. Cela réduit la surface d'attaque du XSS réfléchi, stocké et basé sur le DOM sans avoir à maintenir de longues listes d'autorisation d'hôtes externes, et neutralise les gestionnaires d'événements injectés ainsi que les balises de script inline placées via un template vulnérable. Le nonce est la voie pratique vers une CSP stricte, la configuration recommandée par les équipes de sécurité, sur des pages réelles qui dépendent encore de code JavaScript inline.
Générez le nonce à partir d'une source aléatoire cryptographiquement sûre (au moins 128 bits) et émettez-en un nouveau à chaque réponse ; réutiliser un nonce sur des pages mises en cache en annule l'intérêt. Ne le placez jamais là où un attaquant pourrait le lire et le renvoyer. Associez-le à strict-dynamic pour que les scripts de confiance puissent charger leurs propres dépendances, et conservez une liste d'autorisation d'hôtes en solution de repli pour les anciens navigateurs. Comme un nonce fait toujours confiance à ce qu'un script autorisé exécute au moment de l'exécution, il ne peut arrêter un fichier tiers compromis. cside complète ici la CSP en faisant transiter les scripts tiers par un méthode Script et en analysant la charge utile réelle, bloquant en temps réel les comportements malveillants qu'un nonce valide aurait laissés passer sans encombre.
Oui. Un nonce doit être généré à neuf pour chaque réponse HTTP à l'aide d'un générateur aléatoire sûr. Si vous mettez une page en cache avec son nonce, ou réutilisez la même valeur, un attaquant qui observe un nonce valide pourrait le rejouer dans un balisage injecté, ce qui met à mal la protection. Les pages statiques ou mises en cache nécessitent généralement des hachages à la place.
Les deux permettent d'exécuter des scripts inline précis sous une politique stricte. Un nonce est un jeton aléatoire par requête ajouté à la balise et à l'en-tête, idéal pour les pages rendues côté serveur. Un hachage est une empreinte fixe du contenu exact du script, mieux adaptée au contenu statique ou mis en cache où vous ne pouvez pas apposer un jeton frais à chaque réponse.
We answer client-side security questions every day. Bring yours.