La sécurité web repose sur trois piliers que tout développeur prétend connaître mais que peu maîtrisent vraiment : CSRF, XSS et les cookies httpOnly. Ces trois concepts ne sont pas des buzzwords marketing, mais des vecteurs d'attaque concrets qui compromettent des applications en production chaque jour. Le piège courant consiste à les traiter indépendamment, comme si activer une case à cocher « httpOnly » suffisait. C'est faux. Ces trois mécanismes fonctionnent ensemble, et c'est précisément cette synergie qui crée une défense solide.
CSRF : le vol d'action invisible
CSRF (Cross-Site Request Forgery) exploite la confiance que le navigateur place dans les cookies. Quand vous êtes connecté à votre banque et que vous visitez un site malveillant, ce dernier peut déclencher une action sur votre compte bancaire via une requête silencieuse : transférer de l'argent, modifier vos paramètres, ou supprimer des données. Le navigateur envoie automatiquement les cookies avec la requête, ce qui rend l'attaque transparente pour l'utilisateur. La clé du CSRF c'est que l'attaquant n'a pas accès aux données retournées par la requête—il profite juste du fait que le navigateur envoie les cookies automatiquement. Une balise img, un formulaire caché, ou une requête fetch suffisent. Le vecteur d'attaque classique reste simple : l'attaquant contrôle un site, vous le visitez, et votre navigateur exécute une action sur un autre site auquel vous êtes connecté.
La défense standard contre CSRF utilise des tokens CSRF (aussi appelés tokens d'anti-CSRF). Le serveur génère un token unique, le transmet au client via une réponse HTML ou un endpoint dédié, et le client l'inclut dans les en-têtes HTTP des requêtes modifiant l'état (POST, PUT, DELETE). L'attaquant ne peut pas deviner ce token, donc sa requête échouera. Avec Angular, la gestion des tokens CSRF peut être automatisée via l'intercepteur HTTP. Voici comment : au lieu d'ajouter manuellement le token à chaque requête, Angular peut lire le token depuis un cookie ou un endpoint et l'injecter automatiquement dans l'en-tête X-CSRF-TOKEN. Cela centralise la logique et réduit les oublis.
XSS : quand le JavaScript de l'attaquant devient vôtre
XSS (Cross-Site Scripting) est différent du CSRF. Ici, l'attaquant injecte du code malveillant directement dans votre application. Si un champ de texte accepte du contenu utilisateur sans le nettoyer, un attaquant peut injecter un script qui s'exécute dans le contexte de votre application. Ce script peut alors accéder aux cookies, aux données locales, à l'historique, ou effectuer des actions au nom de l'utilisateur. Angular atténue ce risque en échappant automatiquement le contenu dynamique par défaut. Quand vous utilisez l'interpolation {{variable}} ou les liaisons de propriétés [property], Angular échappe le HTML. Mais cette protection n'est pas magique : elle ne couvre pas les cas où vous contournez intentionnellement le système de sécurité.
Il existe deux formes principales de XSS : le XSS réfléchi et le XSS stocké. Le XSS réfléchi arrive quand un paramètre d'URL est réfléchi sans échappement dans la réponse HTML—par exemple, une page de recherche qui affiche le terme recherché directement. Le XSS stocké est plus grave : du contenu malveillant est sauvegardé en base de données et exécuté chaque fois qu'un utilisateur le consulte. Dans une application Angular, le XSS stocké peut provenir d'un commentaire utilisateur, d'une description de produit, ou de toute donnée provenant d'un formulaire. La mitigation passe par l'échappement systématique et par l'utilisation de Content Security Policy (CSP), une en-tête HTTP qui restreint les sources de scripts autorisées.
httpOnly cookies : la barrière contre le vol de session
Les cookies httpOnly sont une directive simple mais puissante : ils indiquent au navigateur que le cookie ne doit pas être accessible via JavaScript. Seul le navigateur peut le lire et le transmettre automatiquement aux requêtes HTTP. Cela signifie qu'un script XSS ne peut pas faire document.cookie et exfiltrer le token de session. Sans httpOnly, un attaquant qui injecte du JavaScript malveillant peut récupérer votre cookie de session et l'utiliser pour usurper votre identité. Avec httpOnly, ce vecteur est bloqué. C'est une défense en profondeur : même si XSS se produit, le cookie reste sûr. La directive secure complète la protection en forçant le cookie à n'être transmis qu'en HTTPS, éliminant le risque d'interception en clair.
Comment les trois travaillent ensemble
La véritable défense repose sur la combinaison de ces trois éléments. CSRF protège contre les actions non autorisées initiées depuis un autre site. XSS protection et CSP empêchent l'injection de code malveillant. httpOnly cookies protègent la session elle-même. Voici un flux concret : un utilisateur se connecte à votre application Angular. Le serveur envoie un cookie de session avec les drapeaux httpOnly et secure. Simultanément, il fournit un token CSRF via un endpoint ou un cookie lisible en JavaScript. Pour chaque requête POST, PUT ou DELETE, le client inclut ce token CSRF dans l'en-tête X-CSRF-TOKEN. Angular peut automatiser cela via un intercepteur HTTP. Si un attaquant tente une injection XSS, le CSP bloque les scripts non autorisés. Si un attaquant tente une requête CSRF depuis un autre site, le token CSRF manquera et la requête sera rejetée. Si un attaquant parvient quand même à injecter du JavaScript, il ne peut pas lire le cookie httpOnly.
Implémentation concrète avec Angular
Voici un intercepteur HTTP Angular qui gère automatiquement le token CSRF : const httpClient = inject(HttpClient); const httpOptions = { withCredentials: true, headers: new HttpHeaders({ 'X-CSRF-TOKEN': this.getCsrfToken() }) }; private getCsrfToken(): string { return document.querySelector('meta[name="csrf-token"]')?.getAttribute('content') || ''; } Ce pattern suppose que le serveur place le token CSRF dans une balise meta. Le serveur doit également valider le token à chaque requête modifiant l'état. Côté serveur (Node.js/Express par exemple) : app.use(csrf()); app.post('/api/data', (req, res) => { // Le middleware csrf valide le token automatiquement res.json({ success: true }); }); Angular doit aussi configurer les intercepteurs pour inclure le token automatiquement à chaque requête. Cela centralise la logique et réduit les risques d'oubli.
Pièges courants et erreurs de mise en œuvre
Le piège le plus courant est de penser que httpOnly cookies suffisent seuls. Des développeurs activent httpOnly et croient être protégés contre toutes les attaques. Faux. httpOnly ne protège que contre le vol de cookie via JavaScript. Elle ne protège pas contre CSRF. Un attaquant peut toujours forcer une action via une requête silencieuse. De même, activer simplement CSP sans implémenter CSRF n'est pas suffisant. CSP réduit les vecteurs XSS mais ne les élimine pas complètement. Les en-têtes doivent être configurés strictement : Content-Security-Policy: script-src 'self'; default-src 'self'; Trop permissifs, ils deviennent inefficaces. Un autre piège : ne pas valider les tokens CSRF côté serveur. Générer un token et le transmettre au client ne suffit pas. Le serveur doit vérifier que le token reçu correspond à celui de la session. Sans cette validation, le token est juste du théâtre de sécurité.
Un dernier piège : mélanger les stratégies de stockage des tokens CSRF. Certains développeurs placent le token dans un cookie lisible en JavaScript et l'inclus dans un en-tête. D'autres le stockent uniquement en session serveur. La meilleure pratique consiste à le stocker en session serveur et à le transmettre au client via un endpoint ou une balise meta, jamais en cookie lisible. Cela renforce la sécurité car le token ne traverse pas le réseau inutilement.
Conclusion : une défense en profondeur réelle
CSRF, XSS et httpOnly cookies ne sont pas trois solutions indépendantes à cocher. Ils forment une stratégie en profondeur où chacun compense les faiblesses des autres. Implémenter les trois correctement signifie : utiliser des tokens CSRF pour chaque requête modifiant l'état, encoder systématiquement le contenu dynamique et configurer CSP strictement pour prévenir XSS, et enfin, activer httpOnly et secure sur tous les cookies de session. Dans une application Angular en production, automatiser ces mécanismes via des intercepteurs HTTP et des directives de sécurité côté serveur réduit drastiquement le risque d'oubli. La sécurité web n'est jamais « finie », mais ces trois éléments correctement combinés ferment les portes les plus évidentes aux attaquants.