Authentification et autorisation dans les applications générées par IA : pourquoi le login ne suffit pas

Une application générée par IA peut avoir un système de connexion parfait et rester vulnérable. L’utilisateur se connecte via Google, GitHub, email/mot de passe, Auth0, Supabase Auth ou Firebase Authentication ; la session est créée ; le tableau de bord affiche uniquement les boutons prévus. Mais tout cela ne prouve qu’une seule chose : l’application sait qui est l’utilisateur. Cela ne prouve pas ce que cet utilisateur peut lire, modifier, supprimer, exporter ou administrer.

Le risque survient lorsque le code généré par l’IA confond authentification et autorisation. L’authentification répond à la question « qui êtes-vous ? », tandis que l’autorisation répond à la question « que pouvez-vous faire sur cet objet, dans ce tenant, avec ce rôle, dans cet état du workflow ? ». Dans les applications web, SaaS et outils internes créés rapidement avec l’IA, cette seconde partie est souvent la plus fragile.

Le contrôle décisif avant la mise en ligne est simple à décrire mais difficile à improviser : un utilisateur authentifié ne doit pouvoir accéder qu’aux données, fichiers, fonctions, rapports, commandes, projets, espaces de travail et actions qui lui appartiennent réellement. S’il suffit de changer un ID dans une requête pour obtenir les données d’autrui, le login ne protège pas le produit.

[Callforaction-WAPT]

AuthN et AuthZ : la distinction qui détermine la sécurité

AuthN (authentification) signifie identifier l’utilisateur ; AuthZ (autorisation) signifie appliquer des permissions. De nombreux projets générés par IA implémentent bien la première partie car les fournisseurs et les frameworks la rendent rapide : connexion sociale, lien magique, session, jeton de rafraîchissement, middleware de base. La seconde partie nécessite en revanche une connaissance du domaine : rôles, propriété, tenants, états, actions autorisées et frontières entre clients.

L’IA peut générer un tableau de bord qui n’affiche que les enregistrements de l’utilisateur actuel, mais cela ne suffit pas si la requête réelle accepte un user_id provenant du client. Elle peut masquer le bouton “supprimer” aux utilisateurs standard, mais cela ne suffit pas si le point de terminaison (endpoint) DELETE /api/users/123 ne vérifie pas le rôle sur le serveur. Elle peut créer une page d’administration séparée, mais cela ne suffit pas si la route est accessible avec n’importe quelle session.

La règle de base est que l’autorisation doit résider dans le backend, dans les politiques et les contrôles côté serveur, et non uniquement dans l’interface utilisateur (UI). Chaque requête qui lit ou modifie des données doit vérifier l’identité, le rôle, la propriété, le tenant et l’état de l’objet.

BOLA et IDOR dans les applications générées par IA

La vulnérabilité BOLA (Broken Object Level Authorization) est l’un des problèmes les plus répandus dans les API modernes : un utilisateur authentifié manipule un identifiant et obtient l’accès à un objet qui ne lui appartient pas. L’IDOR (Insecure Direct Object Reference) décrit le même problème du point de vue de l’identifiant exposé et modifiable.

Les exemples typiques sont les URL et les corps de requête contenant user_id, account_id, tenant_id, organization_id, project_id, document_id, order_id, invoice_id, ticket_id, message_id, workspace_id. Si l’API utilise cet ID sans vérifier qu’il appartient à l’utilisateur ou au tenant, un attaquant authentifié peut lire ou modifier les données d’autrui.

Les applications générées par IA sont particulièrement exposées à ce risque car le code tend à suivre le chemin le plus direct : prendre un ID dans la route, effectuer une requête, renvoyer le résultat. Cela fonctionne dans la démo et passe les tests de base, mais il manque le contrôle qui lie cet objet à l’identité réelle de l’utilisateur.

Le test le plus simple : changer l’ID

Avant de publier, créez deux utilisateurs et au moins deux ensembles de données similaires. Si l’application est B2B, créez deux tenants ou espaces de travail. Connectez-vous avec le premier utilisateur, interceptez une requête et remplacez l’ID par celui du second utilisateur, en testant la lecture, la mise à jour, la suppression, l’export et le téléchargement.

Ce test doit être effectué sur les API, pas seulement sur l’UI. Utilisez les outils de développement du navigateur (DevTools), un proxy, curl ou un client API et testez les points de terminaison de détail, de liste, de recherche, les pièces jointes, les rapports, les exports CSV, les fonctions d’administration, les invitations, les paiements, les commandes, les notifications et les webhooks. Les vulnérabilités les plus graves se trouvent souvent dans des routes que l’interface n’affiche pas directement.

Le résultat attendu est toujours le même : 403, 404 contrôlé ou réponse refusée. Si l’application renvoie des données, met à jour un enregistrement, supprime un fichier ou produit un export, l’autorisation est rompue.

Isolation des tenants : le problème B2B le plus sous-estimé

Dans les applications SaaS et les outils internes multi-clients, la frontière la plus importante n’est pas seulement entre les utilisateurs, mais entre les organisations. Un utilisateur appartient à un tenant, un espace de travail, une entreprise, une équipe, un projet ou un compte client, et chaque requête doit respecter cette frontière.

Le risque survient lorsque le code filtre par user_id mais oublie le tenant_id, ou lorsqu’il accepte le tenant_id provenant du frontend au lieu de le dériver de la session ou d’une appartenance vérifiée. Un point de terminaison d’export, un tableau de bord d’administration, une fonction de recherche ou une requête agrégée peut exposer des données inter-tenants même si les pages principales semblent correctes.

Pour tester l’isolation des tenants, créez deux organisations avec des données et des rôles similaires, puis essayez de lire des documents, commandes, rapports, utilisateurs, fichiers, factures et journaux du mauvais tenant. Testez également les actions de modification : inviter des utilisateurs, changer de rôle, supprimer des données, exporter des rapports, créer des clés API, visualiser les journaux d’audit. Un seul point de terminaison oublié peut compromettre tout le modèle B2B.

Contrôles uniquement côté client : UI propre, API ouverte

Les constructeurs d’applications par IA sont doués pour créer des interfaces convaincantes : ils affichent des composants différents selon le rôle, masquent des boutons, désactivent des champs, protègent des pages avec des gardes de route et génèrent des menus séparés pour les administrateurs et les utilisateurs standard. Ces contrôles améliorent l’expérience utilisateur, mais ne protègent pas l’application si le backend reste permissif.

Un utilisateur ne doit pas être autorisé parce que le bouton n’apparaît pas, mais parce que le serveur refuse l’action lorsque la permission, le rôle, la propriété ou le tenant ne correspondent pas. Chaque contrôle côté client doit être considéré comme une commodité, et non comme une barrière de sécurité.

Le test pratique consiste à appeler directement les API derrière l’UI : si un utilisateur standard ne voit pas “exporter”, essayez quand même le point de terminaison d’export ; s’il ne voit pas “supprimer”, essayez une requête DELETE ; s’il ne voit pas le panneau d’administration, essayez la route ; si un champ est désactivé dans le formulaire, modifiez le corps de la requête.

Broken Function Level Authorization

La BOLA concerne les objets ; la “Broken Function Level Authorization” concerne les fonctions. Un utilisateur peut ne pas réussir à lire les données des autres, mais réussir tout de même à exécuter des actions réservées à un rôle supérieur : inviter des utilisateurs, changer des rôles, approuver des demandes, émettre des remboursements, publier du contenu, supprimer des espaces de travail, générer des exports ou usurper un compte.

Dans les applications générées par IA, cela arrive lorsque les rôles sont implémentés dans l’UI mais pas dans les routes : le code vérifie que l’utilisateur est connecté, mais pas qu’il est administrateur, propriétaire, gestionnaire de facturation, support ou membre autorisé. Ou bien, il utilise un champ role envoyé par le client au lieu de lire les permissions à partir d’un jeton vérifié ou de la base de données.

Pour chaque fonction sensible, définissez la matrice minimale : qui peut l’exécuter, sur quels objets, dans quel état et avec quelles limites. Puis testez l’action avec un rôle inférieur. Les fonctions d’administration doivent échouer par défaut, et ne pas rester disponibles jusqu’à ce que quelqu’un remarque le problème.

Rôles, permissions et revendications (claims) : où faire confiance et où ne pas le faire

Les rôles et permissions peuvent provenir d’Auth0, Supabase, des revendications personnalisées Firebase, d’une base de données interne ou de systèmes d’entreprise. La partie critique est l’endroit où ils sont vérifiés : le backend doit valider le jeton, la signature, l’expiration, l’émetteur et l’audience lors de l’utilisation de JWT ou de jetons d’accès, puis traduire le rôle et les permissions en décisions applicatives.

Ne faites pas confiance au role, isAdmin, user_id, tenant_id ou aux permissions envoyés dans le corps de la requête par le frontend. Ne faites pas confiance au stockage local (local storage) ni à un champ caché dans le formulaire : un utilisateur peut modifier les requêtes et les en-têtes ; donc, si une décision de sécurité dépend d’une valeur contrôlable par le client, cette décision est fragile.

Dans une application générée par IA, vérifiez où le rôle est calculé. Si le code affiche if (user.role === "admin") dans le frontend, cherchez également le contrôle équivalent côté serveur. S’il n’existe pas, le rôle protège l’interface, pas l’action.

Middleware et nouvelles routes générées par l’IA

Un problème courant est la couverture incomplète du middleware. Le projet possède un middleware d’authentification pour certaines routes, mais l’IA ajoute une nouvelle API, une action serveur, une fonction Edge, une Cloud Function ou un point de terminaison d’export sans le relier au même contrôle, et la route fonctionne mais est oubliée.

Ce risque augmente lorsque l’agent effectue des refactorisations multi-fichiers ou crée des fonctionnalités entières : nouvelles pages, nouveaux gestionnaires, nouveaux modèles, nouveaux points de terminaison et nouveaux tests. Si le modèle d’autorisation n’est pas centralisé, chaque nouvelle route devient une décision manuelle.

Avant la mise en ligne, faites l’inventaire des routes et pour chacune, demandez-vous : nécessite-t-elle une connexion ? Un rôle ? Une propriété ? Un tenant ? Accepte-t-elle un ID du client ? Renvoie-t-elle des données ? Modifie-t-elle l’état ? Produit-elle un export ? Si vous ne pouvez pas répondre, cette route doit être testée.

Workflow hors séquence

Les vulnérabilités d’autorisation ne concernent pas seulement les objets et les rôles, mais aussi l’état du workflow. Une invitation peut être réutilisée, un lien de réinitialisation de mot de passe peut rester valide, une commande peut être modifiée après paiement, une demande peut être approuvée deux fois, un remboursement peut être appelé sans l’état correct, un document peut être publié avant révision.

Le code généré par l’IA peut implémenter les étapes individuelles sans protéger la séquence : l’UI guide l’utilisateur dans le bon flux, mais l’API accepte des appels hors séquence. Il s’agit d’un problème d’abus de logique métier, où l’attaquant ne casse pas le login mais utilise des fonctions légitimes au mauvais moment.

Pour les flux critiques, vérifiez l’état et les permissions ensemble : il ne suffit pas de savoir que l’utilisateur est propriétaire, il faut savoir si l’objet est dans l’état qui autorise cette action. Les invitations, paiements, approbations, exports, publications, suppressions et changements de rôle méritent tous des tests négatifs.

Routes qui échappent souvent à la révision

Les vulnérabilités d’autorisation se trouvent souvent dans les routes secondaires, pas sur l’écran principal. Une page de détail peut être protégée, mais le point de terminaison d’export peut renvoyer plus de données que prévu ; un tableau de bord peut filtrer par tenant, mais une fonction de recherche globale peut interroger toute la base de données ; un téléchargement peut être lié à l’utilisateur, mais le téléchargement peut dépendre uniquement du chemin du fichier.

Contrôlez avec attention les points de terminaison d’autocomplétion, de recherche, d’export CSV, de rapports, de tableaux de bord agrégés, de webhooks, de rappels (callbacks), de notifications, d’upload, de téléchargement, d’aperçus, de fonctions par lots, de tâches cron, d’usurpation d’identité, d’invitations, de réinitialisation de mot de passe, de facturation, de remboursement et de changement de rôle. Ce sont des fonctions souvent ajoutées pour compléter le MVP et moins testées contre les abus.

Les applications générées par IA peuvent créer ces routes comme support à la fonctionnalité principale : le prompt demande “ajouter export”, “ajouter tableau de bord admin”, “ajouter invitation utilisateurs”, “ajouter upload documents”. Le code résultant peut être fonctionnellement correct, mais n’hérite pas toujours des mêmes politiques que les routes déjà existantes.

Exemples pratiques d’abus à tester

Dans un SaaS avec espaces de travail, un utilisateur standard devrait essayer de lire /api/workspaces/{id}/members d’un autre espace de travail, d’exporter les commandes d’un tenant différent, de modifier le rôle d’un collègue, de régénérer une clé API qui n’est pas la sienne ou de télécharger des fichiers chargés par un autre client. Si l’un de ces cas fonctionne, le problème n’est pas dans le login : il est dans le modèle d’autorisation.

Dans une application e-commerce ou une place de marché, essayez de changer order_id, seller_id, customer_id, payment_id et refund_id. Un utilisateur ne doit pas voir les commandes d’autrui, modifier les prix, accéder aux reçus d’autres clients ou appeler des fonctions de remboursement en dehors de son rôle. Les webhooks doivent également être vérifiés : un rappel ne doit pas mettre à jour l’état d’une commande sans valider la signature, l’état et la propriété.

Dans un outil interne généré rapidement, essayez des fonctions qui semblent inoffensives : export, filtres avancés, recherche, duplication d’enregistrement, changement d’assignataire, accès aux commentaires, téléchargement de pièces jointes et visualisation des journaux d’audit. Les outils internes traitent souvent des données d’entreprise sensibles et sont moins durcis car ils ne sont pas perçus comme des produits publics.

RLS et règles de sécurité aident, mais ne suffisent pas seules

La sécurité au niveau des lignes (Row Level Security – RLS) de Supabase, les règles de sécurité Firebase et les contrôles similaires sont des défenses importantes et peuvent bloquer les accès directs à la base de données ou au stockage lorsque l’application utilise des SDK côté client. Ils ne remplacent cependant pas la logique d’autorisation applicative sur les API, les fonctions côté serveur, les exports, les agrégations, les rôles et les workflows.

Si une API côté serveur utilise une clé de service ou un rôle privilégié, elle doit appliquer l’autorisation avant d’exécuter des requêtes ou de renvoyer des données. Si une fonction produit un rapport agrégé, elle doit respecter le tenant et les permissions. Si un point de terminaison exporte des données, il doit avoir des contrôles au moins aussi forts que ceux des écrans qu’il affiche.

Le modèle le plus solide combine plusieurs niveaux : politiques sur la base de données là où c’est nécessaire, contrôles côté serveur centralisés, tests manuels sur les API et les rôles, journalisation des actions sensibles et révision du code sur les zones de contrôle d’accès.

Comment corriger sans multiplier les correctifs fragiles

Lorsque vous trouvez une BOLA ou une fonction accessible au mauvais rôle, évitez de corriger uniquement le point de terminaison spécifique avec une condition locale. Si le problème provient d’un modèle récurrent, il faut centraliser le contrôle : middleware, assistants d’autorisation, politiques partagées, constructeurs de requêtes sécurisés ou couche de service peuvent réduire le risque que la prochaine route générée par l’IA répète la même erreur.

La remédiation devrait partir du modèle : quels rôles existent, quels objets protègent-ils, quels tenants séparent-ils, quelles actions sont autorisées et quels états du workflow sont valides. Ensuite, le code doit appliquer ce modèle de manière uniforme, car si chaque route décide de manière autonome ce que signifie “admin” ou “propriétaire”, la sécurité dépend de la mémoire du développeur individuel ou du prompt utilisé par l’agent.

Pour chaque bug corrigé, ajoutez un test négatif. Si un utilisateur pouvait lire un document d’un autre tenant, le test doit démontrer qu’il reçoit désormais une réponse refusée. Si un rôle bas pouvait appeler un point de terminaison d’administration, le test doit rester dans le pipeline. La correction ne devient fiable que lorsque le comportement erroné ne peut pas revenir sans échouer à un contrôle.

Tests négatifs indispensables

Les tests générés par l’IA couvrent souvent le chemin heureux : connexion réussie, utilisateur correct, donnée existante, rôle prévu. Pour les autorisations, il faut des tests opposés, où chaque fonction critique démontre que le mauvais utilisateur ne peut pas exécuter l’action.

Préparez des cas pour : utilisateur non authentifié, jeton expiré, rôle insuffisant, tenant différent, objet d’un autre utilisateur, ID inexistant, méthode HTTP différente, corps de requête manipulé, état non valide, invitation déjà utilisée, lien expiré, export non autorisé, upload hors chemin et suppression non autorisée.

Ces tests ne doivent pas rester uniquement manuels : après avoir trouvé un problème, transformez-le en test de régression. Les applications générées par IA changent rapidement, donc si un agent modifie un middleware ou une requête, un test négatif doit s’en apercevoir.

Quand une vérification indépendante est nécessaire

Une révision interne peut suffire pour des prototypes sans données réelles, sans utilisateurs externes et avec peu de routes. Une vérification indépendante est nécessaire lorsque l’application est exposée en ligne, gère des données réelles, possède des rôles différents, utilise des tenants ou des espaces de travail, expose des API, produit des exports, gère des paiements, utilise des fonctions d’administration ou provient de modifications importantes générées par l’IA.

Le WAPT (Web Application Penetration Test) est particulièrement utile car il teste le comportement réel de l’extérieur et en tant qu’utilisateur authentifié : il ne se limite pas à lire le code, mais teste les ID manipulés, les routes cachées, les rôles insuffisants, les tenants croisés et les flux hors séquence. La revue de code (Code Review) est utile lorsqu’il faut comprendre pourquoi le contrôle manque : middleware non appliqué, requête erronée, rôle lu depuis le client, politique incomplète, logique dupliquée. Les deux approches sont souvent complémentaires : l’une démontre l’abus, l’autre identifie la cause.

Comment ISGroup peut vérifier l’authentification, les rôles et les API

ISGroup peut tester les autorisations d’une application générée par l’IA en partant du comportement réel : utilisateurs, rôles, API, tenants, objets, fonctions d’administration, exports, uploads et workflows critiques. L’objectif est de démontrer si un utilisateur authentifié parvient à sortir de son périmètre avant la mise en ligne.

Si l’app générée par IA a…	Risque principal	Contrôle conseillé
Web app, API, login, rôles, tenants ou uploads exposés en ligne	BOLA, IDOR, contournement d’auth, abus de rôles	Web Application Penetration Testing
Middleware, requêtes, contrôleurs, actions serveur ou politiques dans le code	Contrôles côté serveur incomplets	Code Review
Supabase, Firebase, Auth0, RLS, règles de sécurité ou callbacks	Politiques et configurations incohérentes avec la logique applicative	Cloud Security Assessment
Plusieurs versions générées par IA sur l’auth et les API	Régressions répétées sur le contrôle d’accès	Software Assurance Lifecycle

Vous avez une application web générée par IA avec login, rôles, tenants ou API exposés ? ISGroup peut vérifier si des utilisateurs authentifiés parviennent à accéder à des données ou des fonctions hors périmètre avant la mise en ligne.

Évidences à préparer

Préparez les URL des environnements, les dépôts (repositories), la liste des routes et API, les rôles, les tenants ou espaces de travail, le fournisseur d’authentification, le schéma de données, les politiques de base de données, les middlewares, les fonctions d’administration, les exports, les uploads, les paiements et les parties générées ou modifiées par l’IA.

Des comptes de test réalistes sont nécessaires : au moins deux utilisateurs standard, un administrateur, deux tenants ou espaces de travail si présents, des données similaires entre les utilisateurs et des objets avec des ID connus. Pour chaque rôle, indiquez quelles actions il devrait pouvoir faire et lesquelles doivent être refusées.

S’il y a des zones incertaines, apportez-les immédiatement à la révision : routes ajoutées par l’IA, contrôles dupliqués, middleware non centralisé, RLS non vérifiée, revendications (claims) utilisées côté frontend, exports créés pour la démo, fonctions d’administration non documentées.

Décision avant la mise en ligne

Bloquez la mise en ligne si :

• Un utilisateur authentifié peut lire, modifier, supprimer ou exporter des données d’autres utilisateurs ou tenants.
• Un rôle bas peut accéder à des fonctions d’administration.
• L’API fait confiance aux ID ou aux rôles envoyés par le client.
• Une route sensible ne vérifie pas la session et les permissions.
• Un workflow critique peut être exécuté hors séquence.

Vous pouvez planifier après la sortie uniquement les améliorations qui n’exposent pas de données ou de fonctions : refactorisation du modèle RBAC, documentation des rôles, augmentation de la couverture des tests, centralisation progressive du middleware. Les résultats concernant BOLA, IDOR, l’isolation des tenants et les fonctions d’administration non autorisées doivent être corrigés avant l’utilisation avec des données réelles et des utilisateurs externes.

Checklist authentification et autorisations

• Listez toutes les routes qui lisent, modifient, suppriment ou exportent des données.
• Associez chaque route au rôle, à la propriété, au tenant et à l’état requis.
• Testez les ID manipulés : user_id, tenant_id, project_id, order_id, document_id, invoice_id.
• Testez différents utilisateurs, différents tenants, jetons absents, jetons expirés et rôles bas.
• Appelez les API directement, sans passer par l’UI.
• Vérifiez les fonctions d’administration : invitation, export, suppression, changement de rôle, usurpation d’identité, remboursement, approbation.
• Contrôlez que le backend ne lit pas le rôle ou l’ID utilisateur depuis le client.
• Vérifiez le middleware sur les nouvelles routes, actions serveur, fonctions et webhooks.
• Ajoutez des tests négatifs pour chaque bug trouvé.
• Ne publiez pas si un utilisateur peut sortir de son périmètre.

Questions fréquentes

• Si j’utilise Auth0, Supabase Auth ou Firebase Authentication, suis-je protégé ?
• Non. Ces outils authentifient l’utilisateur, mais votre application doit toujours autoriser l’accès aux données, objets, rôles et fonctions.
• Comment savoir si j’ai une BOLA ?
• Connectez-vous en tant qu’utilisateur A, interceptez une requête avec l’ID d’un objet et remplacez-le par un ID de l’utilisateur B. Si vous recevez des données ou réussissez à modifier l’objet, vous avez un problème.
• Masquer un bouton dans l’UI est-il suffisant ?
• Non. L’API derrière ce bouton doit refuser la requête même si elle est appelée directement, indépendamment de ce que montre l’interface.
• Les RLS ou les règles de sécurité Firebase suffisent-elles ?
• Ce sont des contrôles importants, mais vous devez également vérifier les API côté serveur, les exports, les fonctions d’administration, le stockage, les workflows et les middlewares.
• Quand le WAPT est-il nécessaire ?
• Lorsque les applications et les API sont exposées en ligne ou sur le point de l’être. Le WAPT teste les rôles, objets, tenants et routes comme le ferait un attaquant authentifié.
• Quand la revue de code est-elle nécessaire ?
• Lorsque vous devez comprendre si les contrôles côté serveur, middlewares, requêtes, rôles et politiques sont implémentés correctement dans le code généré ou modifié par l’IA.

[Callforaction-WAPT-Footer]

Sources et références utiles

• OWASP API Security Top 10 : https://owasp.org/www-project-api-security/
• OWASP Broken Access Control : https://owasp.org/Top10/en/A01_2021-Broken_Access_Control/
• OWASP ASVS : https://owasp.org/www-project-application-security-verification-standard/
• OWASP Authorization Cheat Sheet : https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html