Les 10 failles que nous avons le plus trouvées en 2025-2026

Un an d'audits, des patterns clairs

Après plus d'un an d'revues externes sur des applications web françaises, des patterns clairs émergent. Les mêmes vulnérabilités reviennent encore et encore. Voici notre top 10, classé par fréquence de découverte.

Faille 1 : Politiques RLS manquantes ou incorrectes (78% des audits)

C'est la faille numéro un, de loin. Sur les applications utilisant Supabase ou un backend avec accès direct à la base de données, les politiques Row Level Security sont absentes, incomplètes (SELECT protégé mais pas UPDATE/DELETE), ou permissives (USING(true)). Résultat : tout utilisateur authentifié accède aux données de tous les autres.

Cette faille est particulièrement fréquente dans les applications construites avec des outils IA (Lovable, Bolt) qui génèrent du code fonctionnel mais sans contrôle d'accès.

Faille 2 : Webhooks non authentifiés (62% des audits)

Des URLs de webhooks (n8n, Make, Zapier, custom) hardcodées dans le JavaScript frontend. N'importe quel visiteur peut déclencher ces webhooks avec des paramètres arbitraires. Nous avons trouvé des webhooks permettant la création de comptes admin, l'envoi d'emails, la modification de données, et le déclenchement de workflows coûteux.

Faille 3 : Clés API exposées dans le JavaScript (58% des audits)

Des clés API, tokens de service, et secrets d'application visibles dans le bundle JavaScript. Stripe secret keys, clés Supabase service_role, tokens d'API tiers. Ces clés donnent un accès direct aux services sans aucune restriction.

Faille 4 : IDOR : accès aux données d'autres utilisateurs (52% des audits)

Insecure Direct Object Reference : changer un ID dans l'URL ou dans un paramètre d'API pour accéder aux données d'un autre utilisateur. Les IDs séquentiels rendent l'exploitation triviale : il suffit d'incrémenter.

Faille 5 : Endpoints API sans authentification (48% des audits)

Des routes API accessibles sans aucun token ou session. Endpoints retournant des listes d'utilisateurs, des données de configuration, des statistiques, des exports. Souvent des endpoints créés pour le développement et oubliés en production.

Faille 6 : Configuration exposée : Ziggy, Debugbar, Swagger (41% des audits)

Ziggy qui expose toutes les routes Laravel sur les pages publiques. Laravel Debugbar actif en production avec les requêtes SQL visibles. Swagger UI accessible sans authentification documentant toute l'API.

Faille 7 : Buckets de stockage sans politique d'accès (38% des audits)

Documents confidentiels (bulletins de paie, contrats, pièces d'identité, dossiers médicaux) dans des buckets S3 ou Supabase Storage accessibles par URL directe. Pas de vérification d'identité, pas d'expiration des URLs.

Faille 8 : WordPress REST API exposant des données sensibles (35% des audits)

Endpoints WordPress par défaut retournant la liste des utilisateurs, les options ACF (contenant des clés API), et les médias avec des IDs séquentiels. Les plugins ajoutent des namespaces REST avec des endpoints non authentifiés.

Faille 9 : Absence de rate limiting (31% des audits)

Pas de limite sur les tentatives de connexion (brute force possible), les appels API (déni de service), les créations de compte (spam), et les exports de données (exfiltration massive).

Faille 10 : Headers de sécurité manquants (89% des audits : mais impact moindre)

Absence de Content-Security-Policy, X-Frame-Options, Strict-Transport-Security. Techniquement présent dans presque tous les audits mais avec un impact de sécurité plus limité que les failles précédentes.

Ce que ces chiffres montrent

La majorité des failles ne sont pas des attaques sophistiquées. Ce sont des oublis de configuration, des contrôles d'accès absents, et des secrets exposés. Des failles évitables avec un audit. Notre Revue Externe (1 900€) identifie les failles critiques. L'Audit Complet (4 200€) couvre l'intégralité de cette liste et fournit un plan de remédiation priorisé.