Applications, sites et API

Particuliers et entreprises

Injection de scripts dans une page

Cross-site scripting — XSS

Un site fait exécuter au navigateur d’un visiteur du code glissé dans son contenu.

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

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

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

Une faille XSS, pour cross-site scripting, fait exécuter dans le navigateur une donnée que le site aurait dû afficher comme du texte. Par exemple, un commentaire piégé peut modifier la page ou déclencher une action avec votre connexion. Cela peut arriver sur le vrai site, sans vous envoyer vers une imitation. Le développeur doit empêcher que les données reçues soient traitées comme des instructions.

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

Si vous développez le site, affichez les textes comme des données et nettoyez le HTML dont vous autorisez l’usage. Adaptez la protection à l’endroit où la donnée est insérée, y compris dans les aperçus et l’administration.

Un point à vérifierUne 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 ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Oui, si le forum traite le commentaire comme du code. HTTPS protège les échanges avec le site, sans corriger le traitement de ses commentaires. Le navigateur peut alors effectuer des actions avec votre session.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Un commentaire est interprété comme du contenu actif

Sur le forum étudié, une donnée fournie par un utilisateur devient du code dans le navigateur d’un autre : c’est une XSS. Le défaut peut venir du serveur qui construit la page ou du JavaScript qui ajoute le commentaire après le chargement. Pour le retrouver, suivez la donnée jusqu’à son affichage, même si le HTML envoyé au départ semble correct.

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.

Quelles informations comparer

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.

Ce que ces indices ne permettent pas de conclure

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

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

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 ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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 comprendre votre situation et trouver de l’aide : 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