09. Stockage, XSS et CSRF

Comprendre le mécanisme

Un bearer token volé peut être rejoué par son détenteur dans le périmètre accepté. Stocker une valeur dans localStorage la rend accessible aux scripts de l’origine ; une XSS peut donc la lire. Un cookie HttpOnly empêche cette lecture directe via les API JavaScript habituelles, mais le navigateur peut encore envoyer le cookie sur des requêtes. Aucun de ces choix ne supprime les risques du navigateur.

Raisonner et vérifier

Comparez exposition au script, envoi automatique, politique SameSite, durée et révocation. Un modèle avec serveur intermédiaire conservant les tokens côté serveur peut réduire leur exposition au navigateur, mais conserve ses propres exigences de session et CSRF. Ne placez pas de bearer token dans une URL susceptible d’être journalisée. Testez le modèle choisi avec un contrôle d’origine et des mutations protégées.

Scripts de l’origine

Les scripts d’origine peuvent lire localStorage. L’API de stockage est accessible au JavaScript autorisé dans l’origine. Un script exécuté sur l’origine peut accéder à localStorage. Une XSS ou un script tiers compromis dans ce contexte peut donc lire un bearer token stocké ainsi et l’exfiltrer.

Portée de HttpOnly

Un cookie HttpOnly limite la lecture directe par script. Le script peut encore agir dans le contexte compromis. HttpOnly bloque la lecture directe du cookie par JavaScript. Le script injecté peut encore agir dans la page et déclencher des demandes authentifiées ; cette protection ne supprime pas toutes les conséquences d’une XSS.

Envoi automatique

Les cookies peuvent être envoyés automatiquement. Le navigateur applique sa politique d’envoi. Les cookies sont joints selon leur portée et les règles du navigateur. Cette commodité crée un besoin de protection CSRF sur les actions sensibles, distinct de la confidentialité du cookie.

Comparer les menaces

Le modèle doit comparer XSS et CSRF. Les capacités de lecture et d’envoi diffèrent. Évaluez lecture et exfiltration de credentials, action depuis la page et envoi automatique depuis un autre site. Le choix de stockage doit répondre à ces scénarios concrets plutôt qu’à une règle universelle.

URL

Un bearer token en URL peut fuiter par des traces. Le chiffrement du canal n’efface pas l’historique et les logs. Un bearer token dans la query peut finir dans historique, logs et références. Préférez le canal prévu par le protocole et configurez aussi la minimisation des traces côté proxy et application.

Backend intermédiaire

Un backend intermédiaire peut conserver les tokens côté serveur. La session navigateur reste à protéger. Un BFF peut conserver les tokens côté serveur et exposer une session au navigateur. Il faut alors protéger session, CSRF et échanges internes ; déplacer un secret ne retire pas tous les risques.

Durée d’usage

La durée limite une fenêtre d’usage selon le contrat. La longueur ne définit pas le cycle de vie. Un token court borne une fenêtre selon la validation d’expiration. Il reste utilisable durant cette fenêtre par un voleur ; la durée ne remplace ni prévention XSS ni politique de retrait.

Chiffrement et porteur

Le chiffrement d’un token ne protège pas sa réutilisation comme bearer. Le détenteur peut parfois présenter la valeur sans la déchiffrer. Si le serveur accepte la chaîne chiffrée comme bearer, un voleur peut la rejouer sans la déchiffrer. La confidentialité des claims et la prévention de réutilisation sont des propriétés distinctes.

Parcours réel

La politique de cookies doit être vérifiée sur le parcours réel. Il faut observer les attributs effectivement émis. Vérifiez attributs et envoi des cookies dans les contextes effectivement utilisés : navigation, iframe, sous-domaines et requêtes cross-origin. Un test isolé sur une seule page peut manquer une frontière importante.

Logout défini

Le logout doit définir ce qu’il retire. Les validateurs ne dépendent pas de cette seule suppression. Effacer une valeur locale retire cette copie, pas toutes les copies distribuées. Définissez ce que le serveur invalide et le délai de refus attendu, puis testez une ancienne valeur conservée hors du navigateur.

Atelier guidé : lire, expliquer et vérifier le code

localStorage.setItem('lab-access-token', 'public-fixture-only');
const value = localStorage.getItem('lab-access-token');

Le script écrit puis relit le token de laboratoire dans localStorage : les scripts de cette origine y ont donc accès. N’utilisez aucune valeur réelle pour cette démonstration. Comparez ensuite avec les propriétés d’un cookie HttpOnly, en gardant les scénarios d’action XSS et de CSRF dans l’analyse.

localStorage est exposé aux scripts de l’origine. HttpOnly est un attribut de cookie, pas de localStorage. Le nom de clé n’établit pas un contrôle d’accès. Le stockage ne dépend pas de cette autorité.

Travail pratique : Comparez une session cookie et un token lisible par JavaScript sur un même portail local. Listez trois menaces de chaque modèle.

Critères de correction : Vérifiez les attributs réels du cookie, les accès du script et les chemins de mutation. Documentez les contrôles XSS et CSRF sans annoncer qu’un attribut unique les élimine.