0Pricing
Frontend Academy · Leçon

Content Security Policy : nonce et hachage

Rédigez une CSP stricte avec des nonces pour les scripts intégrés, des hachages pour les extraits connus et report-uri pour surveiller les violations en production.

Content Security Policy : nonce et hachage est une leçon Frontend Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Frontend Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Frontend Academy comprend 4 leçons au total.

Récapitulatif de CSP

La CSP est un en-tête HTTP qui définit ce que le navigateur est autorisé à charger — scripts, feuilles de style, images, polices, cadres et connexions. Défense en profondeur : même si une attaque XSS franchit vos filtres, la CSP bloque souvent la charge utile.

Anatomie d'un en-tête CSP

Chaque directive répertorie les sources autorisées. 'self' signifie « même origine ». Des URL précises peuvent également être autorisées.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://api.example.com;
  font-src 'self' https://fonts.gstatic.com;
  frame-ancestors 'none';
  base-uri 'self';

Directives courantes

default-src : solution de repli pour tout. script-src : JavaScript. style-src : CSS. img-src : images. connect-src : fetch/XHR/WebSocket. font-src : polices. frame-ancestors : sites autorisés à vous intégrer dans une frame (protection contre le détournement de clics).

'unsafe-inline' — la faille courante

De nombreux sites ajoutent 'unsafe-inline' pour autoriser les balises <script> et les attributs onclick intégrés. Cela annule l'objectif principal de la CSP — les charges utiles XSS peuvent s'exécuter directement dans la page. Remplacez-le par des nonces ou des hash.

Nonces — liste blanche à usage unique

Générez un nonce aléatoire pour chaque requête. Ajoutez ce nonce aux scripts intégrés légitimes. Le navigateur n'autorise que les scripts dont le nonce correspond.

// Server (Express middleware):
import crypto from 'crypto';

app.use((req, res, next) => {
  res.locals.nonce = crypto.randomBytes(16).toString('base64');
  res.setHeader('Content-Security-Policy',
    `script-src 'nonce-${res.locals.nonce}' 'strict-dynamic'`
  );
  next();
});

// Template:
<script nonce="<%= nonce %>">window.config = {...};</script>

'strict-dynamic'

Combinez un nonce avec 'strict-dynamic' : les scripts de confiance (ceux qui possèdent le nonce) peuvent charger d'autres scripts. Il n'est ainsi plus nécessaire de répertorier l'URL de chaque source de script. C'est la meilleure pratique actuelle pour la CSP.

Hash — liste blanche statique

Pour les scripts intégrés connus et immuables (par exemple, si votre compilation produit toujours le même extrait d'initialisation), calculez son SHA-256 et ajoutez-le comme hash source. Aucun nonce par requête n'est nécessaire.

// Hash of: console.log('hi');
Content-Security-Policy: script-src 'sha256-XwCNuB+/RUgPlAACI+yHrUKqUsm4zlpGV/Q8tEUx0Q4='

Hash pour les styles intégrés

La même technique s'applique aux balises <style> intégrées : calculez leur hash et ajoutez-le à style-src. C'est préférable à 'unsafe-inline' pour le CSS.

Mode rapport de la CSP

Utilisez Content-Security-Policy-Report-Only pour tester une politique sans l'appliquer. Les violations sont signalées à votre point de terminaison, mais rien n'est bloqué. C'est idéal pour déployer progressivement la CSP.

Content-Security-Policy-Report-Only: 
  default-src 'self';
  report-uri /csp-violations

// /csp-violations receives POSTs like:
{
  "csp-report": {
    "document-uri": "https://example.com/",
    "violated-directive": "script-src 'self'",
    "blocked-uri": "https://evil.com/x.js"
  }
}

report-to (moderne)

report-to + Reporting-Endpoints est le remplacement moderne de report-uri. Les données sont les mêmes, mais leur structure est plus claire.

Reporting-Endpoints: csp="/csp-reports"
Content-Security-Policy: script-src 'self'; report-to csp

Intégrations avec les frameworks

Next.js : définissez la CSP via middleware.ts ou les en-têtes de next.config.js. Nuxt : utilisez le module nuxt-security. Vite : configurez les en-têtes du serveur de développement ; en production, utilisez la configuration des en-têtes de votre hébergeur (Vercel, Netlify).

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [{
        key: 'Content-Security-Policy',
        value: "default-src 'self'; script-src 'self' 'strict-dynamic'"
      }]
    }];
  }
};

Tester la CSP

Ouvrez DevTools → Console : les violations de CSP y sont consignées. Utilisez https://csp-evaluator.withgoogle.com/ pour évaluer votre politique. Commencez par le mode de rapport uniquement en production ; appliquez ensuite la politique après avoir corrigé toutes les violations.

Vérification rapide

Pourquoi 'unsafe-inline' dans une directive script-src est-il considéré comme une faiblesse de la CSP ?

Récapitulatif&nbsp;: bonnes pratiques CSP

Définissez l'en-tête Content-Security-Policy avec des directives adaptées à chaque type de ressource. Évitez 'unsafe-inline' — utilisez des nonces + 'strict-dynamic' ou des hash SHA. Définissez frame-ancestors 'none' (ou 'self'). Testez d'abord en mode Report-Only. Envoyez les violations à /csp-violations (ou utilisez report-to, la solution moderne). Les frameworks prennent en charge la CSP via un middleware ou des en-têtes de configuration.

Questions Fréquemment Posées

La leçon « Content Security Policy : nonce et hachage » est-elle gratuite ?

Oui — le texte complet de « Content Security Policy : nonce et hachage » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Frontend Academy, passe à CoddyKit PRO. Le cours Frontend Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Content Security Policy : nonce et hachage » ?

Rédigez une CSP stricte avec des nonces pour les scripts intégrés, des hachages pour les extraits connus et report-uri pour surveiller les violations en production. Tu pratiques Frontend Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Frontend Academy ?

Aucune expérience préalable n'est requise. Frontend Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Content Security Policy : nonce et hachage » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Frontend Academy ?

Oui. Chaque leçon Frontend Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Prévention des XSS : encodage de sortie et CSP
  2. CSRF : cookies SameSite et jetons
  3. Content Security Policy : nonce et hachage
  4. Flux OAuth côté frontend
← Retour à Frontend Academy