L’owasp top 10 2026 arrive dans un paysage profondément remodelé par la généralisation du code généré par IA, les agents autonomes et l’enchaînement de microservices que l’on n’audite plus à la main. Le tronc commun reste celui qu’on connaît depuis 2017 — Broken Access Control en tête, injection toujours présente — mais deux nouveautés rebattent les cartes : la montée des SSRF (Server-Side Request Forgery) sur des endpoints internes que l’on croyait inaccessibles, et la classe émergente des vulnérabilités liées aux dépendances IA. Cet article reprend la liste actualisée, analyse les trois catégories qui explosent réellement en 2026, et propose des contremesures concrètes par stack pour Node, Python, PHP et WordPress.

Pourquoi le Top 10 2026 mérite une relecture

L’OWASP (Open Worldwide Application Security Project) maintient depuis 2003 une liste consensuelle des dix catégories de risques applicatifs les plus fréquentes, alimentée par les CVE publiées et les retours des programmes de bug bounty. La dernière révision majeure date de 2021. La cuvée 2025-2026, en cours de stabilisation, intègre pour la première fois la prolifération du code écrit par assistant IA et le risque accru d’enchaînement de failles dans les architectures à agents.

Ce qui a changé concrètement par rapport à la version précédente : SSRF gagne en visibilité, les défauts d’authentification reculent légèrement grâce à la maturation des solutions managed, et une nouvelle catégorie « risques liés à l’IA » fait l’objet d’un Top 10 dédié pour les LLM, à lire en complément.

Les 10 catégories — résumé

Voici la lecture synthétique des dix catégories, avec leur évolution depuis l’édition 2021. Le mouvement est indicatif et reflète la fréquence relative observée sur les programmes de bug bounty européens en 2025.

#	Catégorie	Mouvement vs 2021
A01	Broken Access Control	=
A02	Cryptographic Failures	=
A03	Injection (SQL, NoSQL, OS, LDAP)	=
A04	Insecure Design	+1
A05	Security Misconfiguration	=
A06	Vulnerable and Outdated Components	+1
A07	Identification and Authentication Failures	-2
A08	Software and Data Integrity Failures	=
A09	Security Logging and Monitoring Failures	=
A10	Server-Side Request Forgery (SSRF)	+nouveau pic

Chaque catégorie dispose d’une page dédiée sur owasp.org/Top10/ avec exemples, CWE associés et contremesures. À lire avant tout audit de sécurité applicative sérieux.

Focus sur les 3 qui explosent en 2026

Broken Access Control (encore et toujours)

Première du classement depuis 2021, Broken Access Control concentre 38 % des trouvailles bug bounty sur les SaaS B2B en 2025 selon les rapports HackerOne. La forme la plus commune reste l’IDOR (Insecure Direct Object Reference) : une URL /api/orders/142 qui sert la commande sans vérifier que l’utilisateur en est propriétaire.

// Vulnérable : aucune vérification d'ownership
app.get('/api/orders/:id', auth, async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  res.json(order);
});

// Corrigé : authz scoped sur user
app.get('/api/orders/:id', auth, async (req, res) => {
  const order = await db.orders.findOne({
    _id: req.params.id,
    userId: req.user.id,
  });
  if (!order) return res.status(404).end();
  res.json(order);
});

La règle pratique : les contrôles d’autorisation ne se posent jamais à la couche route mais au niveau du modèle ou d’un middleware centralisé. Toute requête qui charge une ressource doit prouver que l’utilisateur courant peut y accéder, à chaque appel.

Server-Side Request Forgery

SSRF consiste à faire émettre par votre serveur une requête HTTP vers une URL choisie par l’attaquant, généralement pour atteindre un service interne (métadonnées cloud, base interne, intranet). L’endpoint vulnérable est presque toujours « innocent » : un proxy d’image, une preview de lien, un import de RSS.

# Vulnérable : récupère n'importe quelle URL
@app.post("/api/preview")
def preview(url: str):
    r = requests.get(url, timeout=5)
    return {"title": parse_title(r.text)}

# Corrigé : allowlist + résolution DNS verrouillée
ALLOWED_HOSTS = {"example.com", "trusted.fr"}

def safe_get(url: str):
    parsed = urlparse(url)
    if parsed.scheme not in {"http", "https"}:
        raise ValueError("scheme")
    if parsed.hostname not in ALLOWED_HOSTS:
        raise ValueError("host")
    ip = socket.gethostbyname(parsed.hostname)
    if ipaddress.ip_address(ip).is_private:
        raise ValueError("private")
    return requests.get(url, timeout=5, allow_redirects=False)

Une SSRF qui touche le service de métadonnées d’un cloud (169.254.169.254 sur AWS) délivre les credentials de l’instance en clair. Les conséquences sont sévères, immédiates et silencieuses si le logging réseau interne n’est pas en place.

Vulnérabilités liées aux dépendances IA / agents

Le code généré par assistant IA introduit des classes d’erreur récurrentes : exposition de clés en dur dans les exemples copiés-collés, désactivation silencieuse de la vérification TLS pour « débugger », appels concurrents à des bibliothèques abandonnées que le modèle propose par habitude. Pour les agents qui invoquent des outils, les risques d’injection de prompt et d’exfiltration sont réels et nécessitent un cadre dédié — voir notre guide pour auditer le code généré par IA.

L’OWASP publie depuis 2024 un Top 10 dédié aux LLM (projet désormais rattaché à l’initiative GenAI Security), à lire en parallèle du Top 10 web pour qui maintient une application avec composants IA. Pour la comparaison historique avec l’édition de référence, l’OWASP Top Ten Web Application Security Risks garde l’historique complet 2017 et 2021 sur la page projet officielle.

Contremesures par stack

Node.js / Express / NestJS

• Authz centralisée via un middleware can(action, resource) ou une lib comme casl.
• helmet activé par défaut, express-rate-limit sur les endpoints sensibles.
• Requêtes paramétrées partout (prisma, knex, ORM avec bind), jamais de concaténation SQL.
• Allowlist DNS + résolution privée bloquée pour tout fetch sortant côté serveur.
• npm audit --omit=dev en CI, renovate ou dependabot sur le repo.

Python / Django / FastAPI

• Permissions Django via permission_classes ou django-rules, jamais d’obj.user == request.user dispersé.
• ORM Django ou SQLAlchemy avec paramètres liés, RawSQL uniquement si justifié.
• bandit en CI pour le SAST Python, pip-audit sur la lockfile.
• Validation stricte avec pydantic côté FastAPI, refus des champs inconnus.
• Headers de sécurité via django-csp et SecurityMiddleware.

PHP / Laravel / WordPress

• Laravel : Policies pour l’autorisation, Gate::authorize() dans chaque contrôleur sensible.
• Eloquent ou requêtes préparées partout, DB::raw seulement avec bindings.
• WordPress : nonces obligatoires, current_user_can() avant toute action, wp_kses_post() sur tout contenu rendu.
• Plugins maintenus uniquement, wp-cli + plugin-check dans la CI.
• Snyk, composer audit ou roave/security-advisories pour les CVE de dépendances.

Comme le formule OWASP, « access control trusts the request, not the user ». Cette défiance vis-à-vis du payload est la base de tout.

L’audit en 4 étapes : SAST, DAST, dépendances, pentest manuel

Un audit sécurité utile combine quatre couches qui se complètent. Aucune ne suffit seule, mais leur addition couvre 90 % des vulnérabilités courantes.

Étape	Outil type 2026	Couvre	Coût
SAST	Semgrep, SonarQube, CodeQL	Patterns dangereux dans le code	Gratuit à modeste
DAST	OWASP ZAP, Burp, Nuclei	Fuzzing HTTP, mauvaise config runtime	Gratuit à premium
Dépendances	Snyk, Dependabot, Trivy	CVE connues sur libs et images	Gratuit (open source)
Pentest manuel	Bug bounty ou audit ponctuel	Logique métier, chaînage	2 000 à 15 000 €

Sur la couche dépendances, Snyk Learn tient une bibliothèque de fiches pédagogiques utiles pour former l’équipe. Pour le SAST en open source, Semgrep tient le haut du pavé en 2026 grâce à ses règles communautaires nombreuses.

Faire vivre une posture sécurité en équipe

La sécurité n’est jamais un sprint. Trois rituels simples suffisent à entretenir une posture défendable. D’abord, intégrer SAST et scan de dépendances directement dans la CI, avec une politique « PR bloquée si vulnérabilité critique ». Ensuite, planifier une revue trimestrielle des CVE publiées sur les briques utilisées, avec un patch obligatoire sous 30 jours pour la sévérité haute. Enfin, organiser un exercice de threat modeling annuel sur les composants critiques, en s’appuyant sur la nomenclature CWE et le Top 10 OWASP comme grille de lecture.

Pour les équipes solo et petites structures, ces rituels se branchent naturellement sur la stack DevOps minimum sécurisée et complètent les enjeux de performance web 2026 (pilier). Cette approche prolonge l’héritage sécurité WebCreatid que nous documentons depuis les premières attaques de cryptojacking.

Questions fréquentes

Qu’est-ce que l’OWASP Top 10 ?

L’OWASP Top 10 est une liste consensuelle des dix catégories de vulnérabilités web les plus impactantes, publiée par la fondation OWASP. Elle agrège les retours de la communauté, les CVE et les programmes de bug bounty pour offrir aux équipes une grille de lecture prioritaire. C’est la référence implicite de tout audit applicatif depuis bientôt vingt ans.

Quelles sont les nouveautés du Top 10 OWASP 2026 ?

La cuvée 2026 confirme la montée du SSRF en A10, accentue le poids des composants vulnérables (A06) et de l’Insecure Design (A04), et acte la nécessité d’un Top 10 dédié aux LLM publié séparément. Les défauts d’authentification reculent légèrement grâce à la maturation des solutions d’identité managées comme Auth0, Clerk ou WorkOS.

Comment se protéger contre le Broken Access Control ?

Centralisez les contrôles d’autorisation dans un middleware ou une couche policy unique, et exigez que chaque ressource chargée prouve que l’utilisateur courant peut y accéder. Refusez par défaut, autorisez explicitement. Ajoutez des tests d’intégration qui vérifient qu’un utilisateur A ne peut pas lire les ressources d’un utilisateur B, sur chaque endpoint sensible.

Le code généré par IA introduit-il de nouvelles vulnérabilités ?

Oui, plusieurs études 2024-2025 ont mesuré un taux d’erreur sécurité supérieur sur le code généré par assistant IA non revu : clés en dur, désactivation TLS, dépendances obsolètes proposées par habitude du modèle. Le risque ne vient pas de l’IA en soi mais du copier-coller sans relecture. Un workflow de revue ciblée règle largement le problème.

Quels outils SAST utiliser pour auditer son code en 2026 ?

Semgrep s’est imposé en open source grâce à ses règles communautaires nombreuses et à sa rapidité. SonarQube reste pertinent pour les organisations qui veulent une vue qualité plus large. CodeQL, gratuit sur les repos publics GitHub, offre une analyse plus profonde. Pour Python, bandit reste l’outil de base. Combinez toujours SAST avec un scan de dépendances type Snyk ou Trivy.

Audit sécurité de votre application web en perspective ? Nous couvrons l’owasp top 10 2026 sur une semaine type, avec restitution priorisée par sévérité. Présentez-nous votre contexte via le formulaire de contact.