Applications, sites et API

Particuliers et entreprises

Injection de scripts dans une page

Cross-site scripting — XSS

Un contenu injecté fait exécuter du code dans le navigateur d’un autre visiteur.

Révision éditoriale : 23 septembre 2026Comprendre : 2 min · Cas technique et détails : 5 min

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

Une situation concrète

Un commentaire semble banal. En l’affichant, un site vulnérable peut laisser le navigateur le traiter comme du code. Le visiteur voit le vrai site, mais une partie de ce qu’il exécute vient alors de l’attaquant.

Comment cela fonctionne

Le cross-site scripting, ou XSS, apparaît lorsqu’un site traite une donnée reçue comme du code à exécuter dans le navigateur. Un commentaire devrait s’afficher comme du texte ; sur un site vulnérable, il peut au contraire faire modifier l’écran ou déclencher une action avec votre connexion. Vous pouvez donc être sur le vrai site et subir ce piège. La correction consiste, pour le développeur, à empêcher la donnée d’être interprétée comme une instruction.

Comment le piège fonctionne

Un contenu est introduit
Commentaire, lien ou donnée affichée.
Le navigateur le prend pour du code
Le site affiche la donnée comme du code exécutable.
La page est détournée
Affichage, données ou actions de session.

Ce que vous pouvez faire

Vos premiers réflexes

Si une page habituelle redirige ou demande des informations de façon inattendue, interrompez l’action et signalez-la. Le visiteur ne peut pas corriger le code du site.

Si vous êtes responsable du service ou de l’organisation

Développeurs : affichez les textes comme des données, nettoyez le HTML autorisé et protégez chaque contexte d’insertion. Vérifiez aussi les aperçus et l’administration.

Le détail qui change toutUne idée reçue à corriger

Le cadenas HTTPS ne protège pas contre du code malveillant servi par le site lui-même.

À vous de décider

Vous consultez le vrai forum, en HTTPS. Un commentaire piégé peut-il tout de même faire agir votre navigateur ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Oui, si le forum affiche ce commentaire comme du code. HTTPS protège le trajet jusqu’au site, mais ne corrige pas sa façon de traiter les commentaires. Le navigateur peut alors agir avec votre session.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

Un commentaire est interprété comme du contenu actif

Une XSS se produit lorsqu’une donnée fournie par un utilisateur devient du code exécuté dans le navigateur d’un autre. Dans un forum, le problème peut venir du serveur qui construit la page ou du JavaScript qui insère un commentaire après son chargement. Il faut donc suivre la donnée jusqu’à son affichage, y compris lorsque la réponse HTML initiale semble correcte.

Pour un commentaire en texte simple, le navigateur doit afficher les caractères reçus sans les interpréter comme du HTML. Si le produit accepte du texte enrichi, un outil de nettoyage maintenu doit limiter les balises et attributs autorisés. La protection dépend du contexte : un échappement adapté au HTML ne suffit pas dans une URL ou une expression JavaScript.

Le rapport CSP présenté indique qu’un script a été bloqué. La valeur disposition=enforce est importante : en mode report-only, le navigateur aurait envoyé un rapport sans bloquer l’action. Ce rapport ne renseigne pas toutes les exécutions possibles.

Enfin, HttpOnly interdit au JavaScript de lire le cookie, mais pas d’effectuer des requêtes avec la session ouverte. L’enquête doit donc porter sur les actions réalisées et les réponses lues dans l’application, même si le cookie n’a pas été volé.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape

Auteur du contenuDonnée non fiable

API / stockagePersistance

NavigateurOrigine du forum

API de compteActions authentifiées

Action
Enregistrement du commentaire
Auteur du contenu vers API / stockage
Trace Révision rev7
Action
Champ message renvoyé en JSON
API / stockage vers Navigateur
Action sur place
innerHTML : interprétation HTML
Navigateur
Trace Point d’insertion dans la page
Action
Action avec la session s9
Navigateur vers API de compte
Trace Audit métier
Refus / blocage
Réauthentification requise
API de compte vers Navigateur
Action
Après correction : insertion textuelle
API / stockage vers Navigateur
Refus / blocage
CSP enforce bloque un script
Navigateur
Trace Rapport CSP

Comment repérer cette attaque

Indices à rechercher

Des éléments ou redirections inattendus apparaissent sur une page connue.
Des rapports de sécurité du navigateur signalent des scripts inhabituels.
Un contenu saisi par un utilisateur modifie le comportement de l’interface.

Repérer les contenus affichés qui déclenchent une exécution ou une requête inattendue dans le navigateur, les violations CSP et les actions de session non reconnues.

Éléments à croiser

Rapprocher l’URL du rapport CSP, son heure de réception et la version déployée. Vérifier le chemin d’affichage du contenu : un rapport de violation ne démontre pas à lui seul qu’une donnée contrôlée par un attaquant a été exécutée.

Limites de l’interprétation

Une extension, un script légitime mal autorisé ou une politique trop stricte peuvent produire des rapports. Une absence de rapport n’exclut pas une XSS, notamment si le script passe la politique.

Comment réagir

Retirer le contenu malveillant et corriger son mode d’insertion dans la page. Vérifier les aperçus, l’administration et les courriels qui affichent la même donnée, puis purger les caches concernés. Examiner les actions réalisées avec les sessions exposées. Déployer la CSP en contrôlant les fonctions légitimes, sans autoriser globalement tous les scripts pour faire disparaître les alertes.

Vérifier la correction

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

Un commentaire destiné à être du texte reste du texte dans le navigateur, y compris après une mise à jour dynamique.
Les contenus HTML autorisés, URL et attributs sont vérifiés selon leur contexte d’affichage.
La CSP bloque effectivement les contenus interdits ; les actions encore possibles avec une session HttpOnly sont prises en compte.

À vous de raisonner

Le cookie est HttpOnly et un rapport CSP existe. Peut-on exclure toute action abusive dans la session ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Non : un script peut agir avec la session sans lire le cookie. Vérifiez aussi si la CSP bloquait réellement ou fonctionnait seulement en observation, puis examinez les actions réalisées. La correction doit traiter l’affichage de la donnée dans son contexte, y compris les insertions dynamiques.

Consulter les détails techniques

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.

csp-report: Enveloppe réelle du format historique report-uri ; les valeurs de cet exemple sont fictives. Ne pas la confondre avec le format de l’API Reporting.
blocked-uri: La valeur inline désigne un script intégré à la page, pas un domaine externe à bloquer.

Rapport CSP et activité de session

JSON

Rapport CSP fictif au format report-uri. Le format de la Reporting API est différent.

{
  "csp-report": {
    "document-uri": "https://forum.example.test/discussion/42",
    "effective-directive": "script-src-elem",
    "blocked-uri": "inline",
    "disposition": "enforce",
    "original-policy": "script-src 'nonce-DEMO'; object-src 'none'; base-uri 'none'"
  }
}

Préparer une collecte dans votre environnement

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.

Navigateur — rapports de violation CSP
Où les trouver
Sur le collecteur de rapports déclaré par la politique Content-Security-Policy du site. Sans collecteur configuré, les événements historiques ne sont pas disponibles côté serveur.
Quoi relever
Dans un rapport report-uri, lire document-uri (page touchée), effective-directive (règle), blocked-uri (ressource) et disposition. La valeur enforce indique une politique appliquée, report une observation sans blocage.
Accès et prérequis
Accès aux rapports reçus. Le format historique report-uri contient csp-report ; l’API Reporting emploie un autre format. Une politique Report-Only observe sans bloquer.
Documentation : Navigateur — rapports de violation CSP
Chrome DevTools — panneau Network du navigateur
Où les trouver
Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
Quoi relever
Sur la reproduction de test, identifier le champ ou composant qui insère le contenu et l’initiateur d’une requête inattendue. Relier la page chargée à sa version de code.
Accès et prérequis
La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
Documentation : Chrome DevTools — panneau Network du navigateur

Si vous pensez être concerné

Si vous utilisez le service

Si une page habituelle redirige ou demande des informations de façon inattendue, interrompez l’action et signalez-la. Le visiteur ne peut pas corriger le code du site.

Pour l’équipe qui exploite le service

Signalez la page et son contexte au responsable du service.
Faites retirer le contenu dangereux et corriger le point d’insertion.
Évaluez les sessions, actions et données exposées aux visiteurs concernés.

Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

OWASP — Cross Site Scripting Prevention — cheatsheetseries.owasp.org
MDN — Content Security Policy — developer.mozilla.org