Les 10 vulnérabilités de code à traquer en 2026

La plupart des failles de sécurité partent encore d'une poignée de classes de bugs bien connues. Les frameworks sont devenus plus sûrs, mais les erreurs se sont déplacées : dans les handlers d'API, les tâches en arrière-plan, le code d'infrastructure et le code de liaison entre services. Voici la liste que nous vérifions en premier à chaque audit, avec la CWE que vous verrez dans un rapport CodeAuditAgent.

1. Contrôle d'accès défaillant (CWE-639, CWE-862)

De loin la découverte grave la plus fréquente : un endpoint charge un enregistrement par son ID sans vérifier qu'il appartient à l'appelant. L'authentification vous dit qui est l'utilisateur ; l'autorisation doit être appliquée à chaque requête, sans exception.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Injection (CWE-89, CWE-78)

Le SQL construit par concaténation de chaînes, les commandes shell et les expressions de template sont encore partout, généralement dans la seule requête que quelqu'un a écrite à la main pour des raisons de performance. Paramétrez la requête ou passez les arguments sous forme de tableau ; ne concaténez jamais une entrée utilisateur.

3. Secrets codés en dur (CWE-798)

Des clés d'API commitées dans le dépôt, des tokens de test qui se révèlent actifs en production, des clés privées dans des fichiers de configuration. Déplacez-les vers des variables d'environnement ou un gestionnaire de secrets, et renouvelez tout ce qui a été commité un jour : supprimer la ligne ne supprime pas l'historique.

4. Falsification de requête côté serveur (SSRF, CWE-918)

Toute fonctionnalité qui récupère une URL fournie par l'utilisateur, comme les webhooks, les aperçus de liens ou les imports, peut être dirigée vers votre réseau interne ou l'endpoint de métadonnées cloud. Limitez les hôtes à une liste d'autorisation, résolvez et vérifiez l'adresse IP, et bloquez les plages privées.

5. Cross-site scripting (XSS, CWE-79)

Les frameworks modernes échappent le contenu par défaut, si bien que le XSS se cache désormais dans les échappatoires : les props HTML brutes, les moteurs de rendu Markdown et les URL placées dans des attributs href. Assainissez le HTML avec une bibliothèque éprouvée et rejetez les URL javascript:.

6. Désérialisation non sécurisée et eval (CWE-502, CWE-95)

Pickle, le chargement YAML, les flux d'objets Java et l'eval dynamique transforment des données en code. Utilisez plutôt des chargeurs sûrs et du JSON validé par un schéma.

7. Cryptographie faible (CWE-327, CWE-330)

MD5 ou SHA-1 pour les mots de passe, IV statiques, Math.random() pour les tokens. Utilisez un algorithme de hachage conçu pour les mots de passe (Argon2id, bcrypt, scrypt) et une source d'aléa cryptographiquement sûre.

8. Redirections ouvertes (CWE-601)

Un paramètre next ou returnTo qui accepte n'importe quelle URL fait de votre domaine un tremplin de confiance pour le phishing. N'acceptez que des chemins relatifs de même origine.

9. Absence de limitation de débit (CWE-307, CWE-770)

La connexion, la réinitialisation de mot de passe, l'OTP et tout endpoint qui vous coûte de l'argent (e-mail, SMS, appels d'IA) ont besoin de limites par utilisateur et par IP. Sans elles, les attaques par force brute et par explosion de facture sont triviales.

10. Mauvaise configuration de sécurité (CWE-16)

CORS en wildcard avec credentials, mode debug en production, stack traces verbeuses, politiques de bucket trop permissives. Ces problèmes ressemblent rarement à des bugs en revue de code parce qu'ils vivent dans la configuration, et c'est précisément pour cela qu'ils doivent être relus comme du code.

Comment utiliser cette liste

• Vérifiez les classes 1 à 3 sur chaque pull request : ce sont celles qui ont le plus d'impact et qui passent le plus facilement inaperçues.
• Traitez la configuration d'infrastructure et de CI comme du code soumis à revue.
• Consignez la CWE pour chaque découverte afin de suivre les correctifs et de mesurer les tendances.