Liste de contrôle de sécurité pour les applications construites avec l'IA : quoi vérifier avant le lancement

Avant que de vraies personnes utilisent une application que vous avez construite avec l'IA, vérifiez sept points : chaque page et chaque API vérifie qui est l'utilisateur et ce qu'il a le droit de faire; les clés secrètes restent sur le serveur, jamais dans le navigateur ou le clavardage; toutes les entrées sont validées côté serveur; chaque utilisateur ne peut atteindre que ses propres dossiers; la connexion et les points d'accès coûteux ont des limites de requêtes; les dépendances sont à jour; et vous pouvez restaurer vos données en cas de problème. La liste ci-dessous transforme chacun de ces points en tests précis que vous pouvez faire sans lire le code.

Les générateurs d'applications par IA excellent à faire fonctionner les fonctionnalités. Ils ne sont pas automatiquement prudents, car la « prudence » est rarement dans la demande. La plupart des problèmes ci-dessous viennent de choses que personne n'a demandées; la solution est donc généralement de le demander.

Comment utiliser cette liste

Parcourez-la dans l'ordre, et pour chaque point, faites deux choses : demandez à l'IA de vous assurer que c'est pris en charge, et testez-le vous-même. L'IA peut écrire une vérification de permission; seul un test vous dit qu'elle fonctionne. Les points sont marqués ainsi :

• Obligatoire — à faire avant que quiconque d'autre utilise l'application.
• Recommandé — à faire avant d'avoir de vrais utilisateurs ou de vraies données.
• Plus tard — utile à mesure que l'application grandit.

Si vous n'avez qu'une heure, faites tous les points Obligatoires.

1. Authentification : qui est-ce?

L'authentification consiste à confirmer qui est une personne, généralement par la connexion. Consultez ce qu'est l'authentification pour les bases et comment ajouter une connexion à votre application pour les options.

• Obligatoire : chaque page qui affiche des données privées exige une connexion. Test : déconnectez-vous, puis collez directement dans le navigateur l'URL d'une page privée.
• Obligatoire : chaque point d'accès API derrière ces pages exige aussi une connexion, et pas seulement la page. Test : déconnectez-vous, ouvrez l'onglet réseau du navigateur et relancez une requête que l'application a faite pendant que vous étiez connecté.
• Obligatoire : les mots de passe sont stockés sous forme hachée avec un algorithme de hachage lent, jamais en texte clair. Les directives de l'OWASP sur le stockage des mots de passe recommandent Argon2id en premier, avec scrypt, bcrypt ou PBKDF2 comme solutions de rechange. Demandez : « Comment les mots de passe sont-ils stockés? »
• Recommandé : les liens de réinitialisation de mot de passe expirent et ne fonctionnent qu'une fois.
• Recommandé : les témoins de session sont marqués Secure, HttpOnly et SameSite, et la déconnexion met fin à la session côté serveur.
• Plus tard : proposez l'authentification à deux facteurs, ou une connexion par un fournisseur qui l'offre.

Vérifiez chaque route API et chaque page qui renvoie des données utilisateur. Chacune doit rejeter les requêtes des utilisateurs non connectés, côté serveur et non seulement dans le code de la page. Listez les routes que vous avez vérifiées.

2. Autorisation : que leur est-il permis de faire?

L'autorisation est l'étape qui suit la connexion : décider ce que cet utilisateur précis peut voir et modifier. C'est là que les applications construites avec l'IA présentent le plus souvent de graves failles, car l'application semble correcte — le tableau de bord de chaque utilisateur n'affiche que ses propres données — alors que le serveur remettra volontiers les données de n'importe qui si on les demande directement.

• Obligatoire : chaque lecture, mise à jour et suppression vérifie, côté serveur, que le dossier appartient à l'utilisateur actuel (ou à son équipe).
• Obligatoire : testez-le : créez deux comptes, A et B. En tant que A, ouvrez l'un des dossiers de A et notez l'identifiant dans l'URL ou la requête réseau. Connectez-vous comme B et demandez ce même identifiant. B doit obtenir une erreur, et non les données de A.
• Obligatoire : les pages et les points d'accès API d'administration vérifient le rôle de l'utilisateur côté serveur. Masquer le lien d'administration n'est pas une protection.
• Obligatoire : les utilisateurs ne peuvent pas modifier leur propre rôle, prix, solde ou champs de propriétaire en éditant la requête. Test : dans l'onglet réseau, regardez ce qu'envoie une mise à jour de profil. Si elle contient des champs comme role ou isAdmin, demandez à l'IA de les ignorer lorsqu'ils viennent du client.
• Recommandé : les identifiants dans les URL sont difficiles à deviner (identifiants aléatoires plutôt que 1, 2, 3). Ce n'est pas un remplacement des vérifications de permissions, mais cela limite les dégâts lorsqu'une vérification manque.

Pour chaque point d'accès qui lit ou modifie un dossier, vérifiez côté serveur que l'utilisateur connecté en est le propriétaire ou y a accès. Renvoyez une erreur 404 sinon. Montrez-moi ensuite comment vous testeriez cela avec deux comptes.

3. Accès au niveau des lignes dans la base de données

« Accès au niveau des lignes » signifie que chaque ligne d'une table (une réservation, une facture) n'est visible que par les utilisateurs auxquels elle appartient. Il existe deux façons courantes de l'appliquer :

Les deux peuvent être bien faites. Ce qui compte :

• Obligatoire : si le navigateur parle directement à la base de données (certains produits de base de données hébergés le permettent), les règles au niveau des lignes sont activées pour chaque table. Sans elles, n'importe qui avec la clé publique peut lire toute la table.
• Obligatoire : les requêtes filtrent par utilisateur ou équipe actuels, et non par un identifiant envoyé par le navigateur.
• Recommandé : les données partagées (les projets d'une équipe) ont une règle claire sur les membres de l'équipe, appliquée à un seul endroit.

4. Secrets et clés d'API

Une clé d'API est un mot de passe pour un service. Stripe, les fournisseurs de courriel et les fournisseurs d'IA utilisent tous des clés. Pour le contexte, consultez ce que sont les variables d'environnement et les secrets.

• Obligatoire : les clés sont stockées dans les variables d'environnement ou les secrets du projet, jamais écrites dans le code.
• Obligatoire : les clés qui peuvent dépenser de l'argent ou lire des données privées ne sont utilisées que sur le serveur. Test : ouvrez votre site en direct, affichez le code source de la page et les fichiers JavaScript dans les outils de développement, et recherchez le début de votre clé (par exemple sk_). Elle ne doit pas apparaître.
• Obligatoire : les clés n'ont jamais été collées dans le clavardage, un dépôt public ou une capture d'écran. Si c'est le cas, changez-la chez le fournisseur (créez-en une nouvelle, supprimez l'ancienne).
• Recommandé : utilisez des clés restreintes ou limitées lorsque le fournisseur les propose. Stripe, par exemple, recommande des clés restreintes qui n'ont que les permissions dont votre intégration a besoin.
• Recommandé : les clés de test et les clés réelles sont séparées, et l'application en production n'utilise les clés réelles que lorsque vous êtes prêt.

Certaines clés sont conçues pour être publiques — la clé publiable de Stripe (pk_…) ou une clé de cartes limitée à votre domaine. La règle vise les clés qui donnent un pouvoir, et non chaque chaîne qui ressemble à une clé.

5. Validation des entrées

Tout ce qu'un utilisateur envoie — champs de formulaire, fichiers téléversés, paramètres d'URL — peut être n'importe quoi, et pas seulement ce que votre formulaire permet.

• Obligatoire : la validation se fait côté serveur, et pas seulement dans le navigateur. Les vérifications du navigateur sont là par commodité; n'importe qui peut les contourner.
• Obligatoire : les requêtes de base de données utilisent des paramètres, et non du texte assemblé à partir des entrées de l'utilisateur (cela empêche l'injection SQL). Demandez à l'IA de le confirmer.
• Obligatoire : le texte saisi par les utilisateurs est affiché comme du texte, et non exécuté comme du HTML. Test : saisissez <b>bonjour</b> comme votre nom. Vous devriez voir les balises, et non du texte en gras.
• Recommandé : les téléversements de fichiers vérifient le type et la taille, et les fichiers téléversés ne sont pas servis depuis le domaine principal de votre application comme pages exécutables.
• Recommandé : les erreurs affichées aux utilisateurs sont simples (« Une erreur est survenue »); les erreurs détaillées vont uniquement dans les journaux du serveur.
• Recommandé : les webhooks de services comme Stripe vérifient la signature du fournisseur avant d'agir. Voir ce qu'est un webhook.

Ajoutez une validation côté serveur à chaque formulaire et chaque point d'accès API : champs obligatoires, longueurs, formats et valeurs permises. Rejetez tout le reste avec un message clair. N'affichez pas les détails internes des erreurs aux utilisateurs.

6. Limites de requêtes et abus

Une limite de requêtes plafonne le nombre de requêtes qu'une personne peut faire sur une période donnée. Sans elles, n'importe qui peut deviner des mots de passe toute la journée, inonder votre formulaire d'inscription ou faire grimper votre facture d'une API payante.

• Obligatoire : la connexion, l'inscription et la réinitialisation de mot de passe sont limitées par adresse IP et par compte.
• Obligatoire : tout ce qui vous coûte de l'argent par appel — requêtes aux modèles d'IA, SMS, courriels — a une limite par utilisateur et exige une connexion.
• Recommandé : les formulaires publics (contact, liste d'attente) ont une protection anti-pourriel : une limite de requêtes, un champ piège caché ou un CAPTCHA.
• Recommandé : définissez des plafonds de dépenses ou des alertes chez vos fournisseurs payants, pour qu'un bogue ou un attaquant ne puisse pas générer une facture illimitée.

7. Dépendances

Les applications sont construites à partir de paquets libres, et ces paquets présentent parfois des vulnérabilités connues.

• Recommandé : demandez à l'IA de vérifier les vulnérabilités connues (pour les projets JavaScript, npm audit ou l'équivalent de votre gestionnaire de paquets) et de mettre à jour ce qui est touché.
• Recommandé : retirez les paquets que l'application n'utilise plus.
• Recommandé : méfiez-vous des paquets qui ont très peu d'utilisateurs ou dont le nom ressemble à une faute de frappe d'un paquet populaire.
• Plus tard : revérifiez chaque mois ou deux, ou activez des alertes automatiques si votre code est sur GitHub.

8. Sauvegardes et récupération

La sécurité inclut la capacité de se remettre des erreurs — les vôtres, celles de l'IA ou celles d'un attaquant.

• Obligatoire : sachez où se trouvent vos données et si elles sont sauvegardées. Ne présumez rien; vérifiez la documentation de votre hébergeur.
• Recommandé : conservez votre propre exportation périodique des données importantes (par exemple une fonction d'exportation CSV ou une copie de la base de données), stockée ailleurs.
• Recommandé : gardez votre code dans un système de contrôle de version, afin de pouvoir restaurer n'importe quelle version.
• Recommandé : les actions destructrices (supprimer un compte, supprimer un projet) demandent une confirmation, et envisagez une « suppression douce » qui peut être annulée pendant un certain temps.
• Plus tard : testez réellement une restauration une fois. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan.

9. Avant le lancement

• Obligatoire : le site en direct utilise HTTPS partout.
• Obligatoire : les données de démonstration, les comptes de test et les pages de débogage du développement sont retirés.
• Recommandé : une politique de confidentialité indique quelles données vous recueillez et pourquoi — exigée dans de nombreux endroits si vous recueillez des données personnelles. Ne prétendez pas avoir de certifications (SOC 2, HIPAA) que vous n'avez pas.
• Recommandé : vous avez un moyen de recevoir les signalements de problèmes de sécurité, et vous savez comment changer rapidement chaque clé.

Pour une vérification préalable plus large que la sécurité, consultez comment faire passer un prototype IA en production.

Quand faire appel à un examen professionnel

Une liste de contrôle détecte les erreurs courantes; elle ne remplace pas un expert. Envisagez de payer pour un examen si vous traitez vous-même des numéros de carte au lieu de passer par un paiement hébergé, si vous conservez des données de santé, financières ou sur des enfants, si vous vendez à des entreprises qui exigent des questionnaires de sécurité, ou si une fuite vous causerait un préjudice grave. Pouvoir exporter votre code facilite beaucoup un tel examen.

La sécurité lorsque vous construisez sur Mythex

Mythex ne comprend pas de panneau d'analyse de sécurité; la liste ci-dessus est donc le processus à suivre. Quelques éléments utiles :

• Secrets du projet. Stockez les clés dans les paramètres du projet → Secrets, ou par la carte de secrets que l'agent affiche dans le clavardage, afin qu'elles restent hors de votre code et de vos messages. Après avoir modifié un secret pour une application en production, publiez de nouveau.
• Modes Plan et Question. Demandez à l'agent d'examiner les permissions sans rien modifier : « En mode Question, listez chaque route API et la vérification de permission qu'elle effectue. »
• /test demande à l'agent de cliquer dans votre aperçu comme un utilisateur — utile pour le test à deux comptes de la section 2.
• Les points de contrôle vous permettent d'annuler une modification qui a cassé quelque chose.

Voir la sécurité des applications que vous construisez et les variables d'environnement et les secrets dans la documentation. Si vous ajoutez ensuite des comptes utilisateurs, lisez comment ajouter une connexion à votre application.

Questions