Authentification et autorisation

“Vérifier que quelqu'un a un billet, mais ne jamais vérifier que c'est un billet pour ce siège.”

L'authentification n'est pas l'autorisation

Deux questions différentes se cachent derrière « auth ». L'authentification demande qui êtes-vous, prouvé par une connexion. L'autorisation demande à quoi avez-vous le droit de toucher, décidé par requête, par ressource. Elles sont indépendantes : être connecté (authentifié) ne dit rien sur votre droit de lire la commande n°124 (autorisation). Les outils IA réussissent la première parce qu'elle est visible et demandée dans le prompt. Ils ratent la seconde parce que, avec un seul utilisateur de test qui possède tout, elle ne se pose jamais.

Le résultat : une app où la connexion est solide et où, une fois entré, vous pouvez atteindre les données de tout le monde. La porte d'entrée a une bonne serrure ; aucune des portes intérieures n'en a.

Le bug que vous aurez vraiment : l'IDOR

Insecure Direct Object Reference est le nom sans éclat de la faille la plus probable de votre app. Le schéma : une ressource est adressée par un id, et le serveur la renvoie à quiconque est authentifié, sans vérifier la propriété. Votre UI ne vous lie jamais qu'à vos propres enregistrements, donc tout semble en ordre, mais l'id dans l'URL ou dans l'appel API n'est qu'un nombre, et le changer renvoie celui de quelqu'un d'autre.

  you own order 123
  GET /api/orders/123   →  200  { your order }      ✓ correct
  GET /api/orders/124   →  200  { someone else's }  ✗ IDOR: no ownership check
                           ^ the only thing you changed was a number

C'est trivial à trouver et trivial à exploiter : incrémentez un id, lisez la facture d'un inconnu. Et c'est partout dans les apps construites par IA, parce que l'endpoint généré récupère l'enregistrement par id et le renvoie ; la ligne « est-ce que cet utilisateur le possède » est la protection invisible que personne n'a demandée. Une vérification de propriété qui tient.↗

L'auth dérive au fil des prompts

Une défaillance plus subtile : une garde ajoutée dans un prompt disparaît dans un prompt ultérieur sans rapport. Vous demandez à l'outil d'« ajouter du filtrage à cet endpoint », il réécrit le handler, et la vérification de propriété qui s'y trouvait a silencieusement disparu, parce que le modèle a régénéré la fonction autour de la nouvelle demande sans reporter l'ancienne contrainte. L'endpoint renvoie toujours des données, la démo fonctionne toujours, et le trou s'est rouvert sans laisser de trace.

C'est pourquoi la sécurité dans les apps construites par IA ne peut pas être une passe unique. Les vérifications se dégradent chaque fois que vous régénérez du code autour d'elles. Vous re-vérifiez après les changements, ce qui est exactement le rôle de la checklist du chapitre 6.

La règle : vérifier sur le serveur, à chaque fois

Toute défense ici se ramène à une seule discipline : le serveur décide, à chaque requête, à partir de valeurs que le client ne peut pas falsifier :

• Authentifiez chaque requête protégée côté serveur ; ne déduisez jamais l'identité de quelque chose envoyé par le client.
• Autorisez par ressource : CET utilisateur authentifié possède-t-il (ou a-t-il un rôle accordant) CETTE ligne précise ? Pas seulement « est-il connecté ».
• Ne faites jamais confiance à un user_id, un rôle ou un drapeau is_admin fourni par le client ; dérivez l'identité et les permissions de la session vérifiée.
• Refus par défaut : si aucune règle n'accorde explicitement l'accès, refusez. Préférez renvoyer 404 plutôt que 403 pour ne même pas confirmer que la ressource existe.

C'est le même principe que Row-Level Security au chapitre 2, appliqué à la couche applicative plutôt qu'à la base de données. En fait, les deux se renforcent : la RLS attrape ce qu'une vérification applicative manquée laisse passer, et vice versa. La défense en profondeur signifie que vous voulez les deux.