API .NET : 7 failles qu'on croise encore en 2026 (et comment les corriger)
Les API ne tombent pas à cause de hackers de génie.
Elles tombent à cause d'un endpoint de debug oublié en prod, d'un token qui traîne dans les logs, d'un package NuGet pas mis à jour depuis 8 mois.
Des détails. Sauf qu'une API exposée sur internet se fait scanner par des bots en quelques minutes. Et les bots adorent les détails.
Petit rappel avant de commencer : l'OWASP (Open Worldwide Application Security Project) publie le top des failles les plus répandues. Leur API Security Top 10 est la référence sur le sujet.
1. Authentifié ≠ autorisé
GET /api/orders/42. Le token est valide, on renvoie la commande. Mais personne n'a vérifié qu'elle appartient bien à cet utilisateur. C'est la faille n°1 de l'OWASP ces dernières années (la fameuse BOLA, Broken Object Level Authorization) et celle que je croise le plus.
Le fix : vérifiez que le demandeur a bien accès à cette ressource, pas juste à cet endpoint.
2. Les secrets dans appsettings.json
Une connection string ou une clé API commitée sur Git, ça arrive dans toutes les équipes. Et les bots scannent GitHub en continu pour ça.
Le fix : User Secrets en local, Key Vault en prod. Jamais de secret versionné. (Repo privé sur Azure DevOps ? Ça réduit le risque, mais tout le monde a accès à l'historique.)
3. L'over-posting sur vos entités EF Core
Vous bindez l'entité User directement dans votre endpoint, sans passer par un DTO ? Un client ajoute "IsAdmin": true dans le payload et devient admin. Je suis déjà tombé dessus, ça surprend.
Le fix : un DTO propre par endpoint dans votre couche applicative. Vos entités EF ne sortent jamais vers l'extérieur.
4. Swagger ouvert en prod
Pratique pour vous, encore plus pour un attaquant : toute la doc de votre API servie sur un plateau. Et attention, la préprod exposée compte aussi.
Le fix : perso je garde Swagger en local uniquement. Et pour les partenaires, je partage juste les endpoints dont ils ont besoin, pas toute la surface.
5. La stack trace qui raconte tout
Une exception non gérée, et le client reçoit vos namespaces, votre structure interne, parfois votre requête SQL.
Le fix : un middleware d'exception avec ProblemDetails. Erreur propre côté client, détails dans vos logs.
6. Zéro rate limiting sur le login
Un /login sans limite, c'est du brute-force en libre-service.
Le fix : le middleware est natif depuis .NET 7. Quelques lignes, zéro dépendance.
7. Le code IA non relu
La faille de 2026. Votre IA pond une couche d'auth qui compile et qui marche. Mais qui valide mal l'issuer du JWT, ou zappe un cas limite.
Le fix : le code généré passe en review comme le reste. Surtout sur l'auth et la validation des entrées.
Bonus audit : le test man-in-the-middle
Quand j'audite un projet, je me mets en man-in-the-middle avec Charles Proxy.
Dans un sens, je modifie les appels du front : je change des id pour essayer de taper la data d'un autre user (la faille n°1), par exemple. Dans l'autre, je modifie les réponses du back avant l'affichage, avec un "IsAdmin": false qui passe à true, pour voir si j'arrive à ouvrir l'interface admin et tenter des appels derrière.
Vous seriez surpris du nombre d'API qui gobent tout ce que le front leur envoie. Zéro contrôle côté serveur, et là tout devient possible.
Aucune de ces failles ne prend plus d'une heure à corriger. Et chacune peut coûter très cher en prod.