Top 10 des vulnérabilités web en 2025

Ce classement reflète ce que nous observons le plus souvent en pentest web et audit de sécurité applicatif en 2025 - pas une liste académique dérivée de l'OWASP Top 10, mais un repère terrain pour arbitrer vos sprints et vos budgets de remédiation.

Chaque entrée inclut : comment la vulnérabilité se manifeste en pratique, un exemple concret ou un extrait de code, et les correctifs prioritaires.

1. Contrôles d'accès défaillants (IDOR & escalade de privilèges)

Ce que l'on voit. C'est la catégorie la plus fréquente en 2025. Les scénarios les plus courants : un identifiant de ressource exposé dans l'URL ou le corps de la requête (Insecure Direct Object Reference), et une API qui répond sans vérifier que l'utilisateur authentifié possède la ressource demandée.

En pratique, remplacer /api/invoices/1042 par /api/invoices/1041 retourne la facture d'un autre client. L'authentification fonctionne ; l'autorisation, non.

Exemple vulnérable - endpoint sans vérification de propriété (Node.js / Express)

// ❌ Vulnérable : n'importe quel utilisateur authentifié peut lire n'importe quelle facture
app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  res.json(invoice); // aucune vérification de req.user.id vs invoice.ownerId
});

// ✅ Corrigé : vérification explicite de la propriété
app.get('/api/invoices/:id', authenticate, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  if (!invoice || invoice.ownerId !== req.user.id) {
    return res.status(403).json({ error: 'Accès refusé' });
  }
  res.json(invoice);
});

Correctifs. Vérification de propriété côté serveur à chaque accès à une ressource. Ne jamais faire confiance à l'identifiant fourni par le client sans recroiser avec la session. Centraliser les règles d'autorisation dans un middleware ou une couche de politiques dédiée.

2. Injections (SQL, NoSQL, commandes OS)

Ce que l'on voit. Les ORM modernes ont réduit les injections SQL classiques, mais des zones régressent régulièrement : fonctions de recherche avec LIKE dynamique, clauses ORDER BY construites depuis des paramètres client, fonctionnalités d'import/export CSV, et scripts d'administration legacy.

Les injections de commandes OS sont moins fréquentes mais souvent critiques : elles apparaissent dans les fonctions de conversion de fichiers (ImageMagick, FFmpeg), de génération de PDF, ou d'interaction avec des outils CLI internes.

Requête SQL paramétrée - séparation correcte données / instruction (Python / psycopg2)

def fetch_user_row(conn, user_id: int):
    """Le pilote sépare les données de l'instruction SQL - aucun risque d'injection."""
    with conn.cursor() as cur:
        cur.execute(
            "SELECT id, email, role FROM app_users WHERE id = %s",
            (user_id,),   # tuple passé séparément, jamais interpolé dans la chaîne
        )
        return cur.fetchone()

# ❌ Ne jamais faire :
# cur.execute(f"SELECT * FROM users WHERE id = {user_id}")

Correctifs. Requêtes paramétrées systématiques. Pour les clauses dynamiques (ORDER BY, noms de colonnes), valider contre une liste blanche explicite. Pour les appels système, éviter les shells intermédiaires (subprocess.run(..., shell=False)) et valider chaque argument.

3. Cross-Site Scripting (XSS stocké et réfléchi)

Ce que l'on voit. Le XSS réfléchi persiste dans les pages d'erreur, les redirections, et les champs de recherche qui réaffichent la saisie sans encodage. Le XSS stocké est plus sévère : champs de commentaires, noms d'affichage, champs de description dans les outils collaboratifs ou les back-offices.

L'impact varie fortement selon l'emplacement. Un XSS sur un formulaire client exposé publiquement permet le vol de session, la redirection phishing, ou le keylogging. Sur un back-office admin, il peut permettre une escalade vers l'administration de la plateforme.

Ce qui manque le plus souvent. Une Content Security Policy (CSP) restrictive côté serveur. Sans elle, même un encodage correct peut être contourné via des injections dans des attributs d'événement ou des balises SVG.

En-tête CSP minimale - bloquer l'exécution de scripts inline non approuvés

Content-Security-Policy:
  default-src 'self';
  script-src 'self' cdn.jsdelivr.net;
  style-src 'self' 'unsafe-inline' fonts.googleapis.com;
  img-src 'self' data: https:;
  frame-ancestors 'none';

Correctifs. Encodage contextuel en sortie (HTML, JS, URL, attribut). CSP déployée et testée. Attribut HttpOnly sur les cookies de session pour limiter l'impact d'une XSS résiduelle.

4. Gestion de session fragile

Ce que l'on voit. Plusieurs scénarios distincts reviennent en pentest : jetons JWT signés avec un secret faible ou l'algorithme none, absence de rotation du token après authentification (session fixation), déconnexion côté client uniquement sans invalidation serveur, et durées de vie excessives sans rafraîchissement.

La session fixation est souvent sous-estimée : si le serveur conserve le même identifiant de session avant et après le login, un attaquant qui a pu forcer un identifiant connu peut s'authentifier à la place de la victime.

JWT - vérifications essentielles côté serveur (Python / PyJWT)

import jwt

def decode_token(token: str, secret: str) -> dict:
    return jwt.decode(
        token,
        secret,
        algorithms=["HS256"],   # liste blanche explicite - rejette "none" et RS256 inattendu
        options={
            "require": ["exp", "iat", "sub"],  # champs obligatoires
            "verify_exp": True,
        },
    )

Correctifs. Régénérer l'identifiant de session à chaque élévation de privilège. Invalider les tokens côté serveur à la déconnexion (liste de révocation ou store Redis). Durées de vie courtes avec refresh token. Cookies : Secure; HttpOnly; SameSite=Strict.

5. CSRF sur actions sensibles

Ce que l'on voit. Le CSRF est souvent négligé sur les applications qui reposent uniquement sur des cookies de session sans le flag SameSite. Les cas les plus critiques : changement d'adresse e-mail, virement bancaire, suppression de compte, modification de droits.

Beaucoup d'équipes pensent être protégées parce qu'elles utilisent des en-têtes Authorization: Bearer sur leurs API - c'est correct pour les SPA qui lisent le token depuis le localStorage. En revanche, les applications à rendu serveur avec authentification par cookie restent exposées si SameSite n'est pas configuré.

Correctifs. Cookie de session avec SameSite=Strict ou Lax. Pour les actions critiques : jeton anti-CSRF synchronisé (Double Submit Cookie ou Synchronizer Token Pattern). Vérifier l'en-tête Origin ou Referer côté serveur comme défense en profondeur.

6. Upload et traitement de fichiers

Ce que l'on voit. Les portails clients, outils RH et plateformes documentaires introduisent régulièrement des surfaces d'upload. Les contournements fréquents : doubles extensions (malware.php.jpg), MIME type forgé dans le Content-Type, et fichiers SVG contenant du JavaScript (XSS via upload d'image).

Le traitement côté serveur est aussi une surface : des bibliothèques comme ImageMagick ou les parseurs de PDF exposent des vecteurs d'exécution de commandes si les entrées ne sont pas contrôlées en amont (cf. ImageMagick Shell Injection via les noms de fichiers).

Correctifs. Valider le type de fichier par son contenu magique (magic bytes), pas uniquement son extension ou son Content-Type. Stocker les fichiers hors de la racine web, ou dans un bucket isolé. Servir les fichiers utilisateurs depuis un sous-domaine séparé avec une CSP restrictive. Renommer systématiquement le fichier à l'upload.

7. Sécurité des API - endpoints non protégés

Ce que l'on voit. Les applications modernes exposent souvent plusieurs surfaces d'API : l'API web publique, une API mobile avec ses propres routes, et des endpoints d'administration ou d'intégration. Ces surfaces n'ont pas toujours le même niveau de contrôle d'accès.

En pratique : proxy d'interception sur une application mobile, et découverte d'endpoints /api/admin/users ou /api/internal/reports qui répondent sans vérification de rôle, parce qu'ils ont été développés « pour l'usage interne » et jamais soumis aux mêmes revues que l'API publique.

Correctifs. Inventaire complet des routes (outils : Swagger/OpenAPI à jour, tests automatisés des routes non documentées). Appliquer les mêmes middlewares d'authentification et d'autorisation à toutes les routes, y compris celles dites internes. Audit des API mobiles lors des pentests web.

8. Dépendances vulnérables (SCA)

Ce que l'on voit. Les projets accumulent des dépendances directes et transitives dont les CVE s'accumulent. En pentest, on identifie régulièrement des versions de bibliothèques avec des CVE publiées depuis 6 à 18 mois, simplement par analyse des manifestes (package.json, requirements.txt, pom.xml).

Les cas les plus critiques : bibliothèques de désérialisation (Log4Shell en est l'exemple paradigmatique), parseurs XML exposés à l'injection XXE, et bibliothèques d'authentification OAuth avec des failles de validation de token.

Correctifs. Intégrer un outil SCA dans la CI (npm audit, Snyk, Dependabot, OWASP Dependency-Check). Définir une politique de mise à jour : correctifs de sécurité critiques sous 72h, les autres dans le sprint suivant. Ne pas bloquer le pipeline sur les avertissements mineurs, mais bloquer sur les CVE CVSS ≥ 9.

9. Journalisation et surveillance insuffisantes

Ce que l'on voit. Lors des pentests, il est courant de mener des attaques prolongées (scan, énumération, exploitation) sans déclencher la moindre alerte. Les causes principales : logs applicatifs absents ou non structurés, logs centralisés sans règles de détection, et absence de corrélation entre les événements d'authentification et les accès aux ressources.

C'est un problème de détection autant que de remédiation : sans log d'accès aux ressources sensibles, impossible de savoir si une IDOR a été exploitée avant le pentest.

Correctifs. Logger les événements d'authentification (succès, échec, MFA), les accès aux ressources sensibles, les erreurs d'autorisation (403), et les actions d'administration. Structurer les logs en JSON pour faciliter l'ingestion SIEM. Définir des alertes sur les patterns anormaux : séquences de 403 répétées, accès à plage d'identifiants contigus (pattern IDOR automatisé).

10. Mauvaise séparation des environnements

Ce que l'on voit. Des données de production dans des environnements de staging accessibles publiquement, des credentials partagés entre dev et prod, des clés API de production dans des fichiers .env versionnés, et des buckets S3 de staging hébergeant des exports réels.

Ce n'est pas uniquement un risque « web » au sens strict : c'est souvent le chemin le plus court vers les données sensibles, parce que les environnements non-prod bénéficient rarement du même niveau de durcissement que la production.

Correctifs. Données de production anonymisées ou synthétiques dans les environnements inférieurs - sans exception. Credentials distincts par environnement, gérés via un gestionnaire de secrets (AWS Secrets Manager, Vault). Scan automatique des dépôts pour détecter les secrets committes (Gitleaks et équivalents). Accès aux environnements de staging restreints aux IP de l'organisation.

---

Comment prioriser les correctifs

La question n'est pas « quelle est la vulnérabilité la plus grave au sens CVSS ? » mais « quelle faille est exploitable dans mon contexte et quel est son impact réel ? ». Un CVSS 9.8 dans une dépendance interne sans exposition réseau est moins urgent qu'un IDOR CVSS 6.5 sur votre API de facturation publique.

Une grille pratique en trois critères :

• Exposabilité : la vulnérabilité est-elle accessible sans authentification, ou nécessite-t-elle un compte valide ?
• Impact données : les données accessibles sont-elles personnelles, financières, ou stratégiques ?
• Complexité d'exploitation : faut-il une interaction utilisateur, un accès réseau particulier, ou une chaîne d'exploitation ?

Besoin d'une validation concrète sur votre périmètre ? Un pentest web permet de vérifier ce qui est réellement exploitable dans votre contexte - pas ce qui l'est théoriquement selon un score CVSS.