Checklist de sécurité pour les applications créées avec l'IA : que vérifier avant la mise en ligne

Avant que de vraies personnes utilisent une application créée avec l'IA, vérifiez sept points : chaque page et chaque API contrôle 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 ni dans le chat ; toutes les saisies sont validées côté serveur ; chaque utilisateur n'accède qu'à ses propres enregistrements ; la connexion et les points d'accès coûteux sont limités en débit ; les dépendances sont à jour ; et vous pouvez restaurer vos données en cas de problème. La checklist ci-dessous transforme chacun de ces points en tests précis que vous pouvez réaliser sans lire le code.

Les créateurs d'applications IA sont doués pour faire fonctionner les fonctionnalités. Ils ne sont pas automatiquement prudents, parce que la « prudence » figure rarement dans la consigne. La plupart des problèmes ci-dessous viennent de choses que personne n'a demandées, donc la solution consiste en général à le demander.

Comment utiliser cette checklist

Parcourez-la dans l'ordre, et pour chaque point faites deux choses : demandez à l'IA de vous assurer que c'est traité, et testez-le vous-même. L'IA peut écrire un contrôle de droits ; seul un test vous dit qu'il fonctionne. Les points sont marqués ainsi :

• Indispensable — à 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 Indispensables.

1. Authentification : qui est-ce ?

L'authentification consiste à confirmer l'identité de quelqu'un, en général à la connexion. Consultez ce qu'est l'authentification pour les bases et comment ajouter une connexion à votre application pour les options.

• Indispensable : chaque page qui affiche des données privées exige une connexion. Test : déconnectez-vous, puis collez directement l'URL d'une page privée dans le navigateur.
• Indispensable : 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é.
• Indispensable : les mots de passe sont stockés hachés avec un algorithme de hachage lent, jamais en clair. Les recommandations de stockage de mots de passe de l'OWASP privilégient Argon2id, avec scrypt, bcrypt ou PBKDF2 comme alternatives. 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 seule fois.
• Recommandé : les cookies de session sont marqués Secure, HttpOnly et SameSite, et la déconnexion met fin à la session côté serveur.
• Plus tard : proposez une authentification à deux facteurs, ou une connexion via un fournisseur qui la propose.

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

2. Autorisation : que sont-ils autorisés à 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 créées 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.

• Indispensable : chaque lecture, mise à jour et suppression vérifie, côté serveur, que l'enregistrement appartient à l'utilisateur courant (ou à son équipe).
• Indispensable : testez-le : créez deux comptes, A et B. En tant qu'A, ouvrez un de vos enregistrements et notez l'identifiant dans l'URL ou la requête réseau. Connectez-vous en tant que B et demandez ce même identifiant. B doit obtenir une erreur, pas les données de A.
• Indispensable : les pages d'administration et les points d'accès API d'administration vérifient le rôle de l'utilisateur côté serveur. Masquer le lien vers l'administration ne constitue pas une protection.
• Indispensable : les utilisateurs ne peuvent pas modifier leur propre rôle, leur prix, leur solde ou leurs 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 côté 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 contrôles de droits, mais cela limite les dégâts lorsqu'un contrôle manque.

Pour chaque point d'accès qui lit ou modifie un enregistrement, 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 tester 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 faits. Ce qui compte :

• Indispensable : si le navigateur communique directement avec la base de données (certains produits de bases hébergées le permettent), les règles au niveau des lignes sont activées pour chaque table. Sans elles, quiconque possède la clé publique peut lire toute la table.
• Indispensable : les requêtes filtrent par utilisateur ou équipe courant, 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 services d'e-mail et les fournisseurs d'IA utilisent tous des clés. Pour le contexte, voir ce que sont les variables d'environnement et les secrets.

• Indispensable : les clés sont stockées dans les variables d'environnement ou les secrets du projet, jamais écrites dans le code.
• Indispensable : 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 ligne, affichez le code source de la page et les fichiers JavaScript dans les outils de développement, puis recherchez le début de votre clé (par exemple sk_). Il ne doit pas apparaître.
• Indispensable : aucune clé n'a jamais été collée dans le chat, un dépôt public ou une capture d'écran. Si c'est arrivé, régénérez-la chez le fournisseur (créez-en une nouvelle, puis supprimez l'ancienne).
• Recommandé : utilisez des clés restreintes ou limitées lorsque le fournisseur le propose. Stripe, par exemple, recommande des clés restreintes qui n'ont que les autorisations 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 concerne les clés qui confèrent un pouvoir, et non toute chaîne qui ressemble à une clé.

5. Validation des saisies

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 autorise.

• Indispensable : la validation se fait côté serveur, pas seulement dans le navigateur. Les contrôles du navigateur sont là pour le confort ; n'importe qui peut les contourner.
• Indispensable : les requêtes à la base de données utilisent des paramètres, et non du texte assemblé à partir de la saisie de l'utilisateur (c'est ce qui prévient l'injection SQL). Demandez à l'IA de le confirmer.
• Indispensable : le texte saisi par les utilisateurs est affiché comme du texte, et non exécuté comme du HTML. Test : saisissez <b>bonjour</b> comme nom. Vous devez voir les balises, pas un texte en gras.
• Recommandé : les fichiers téléversés voient leur type et leur taille vérifiés, et les fichiers envoyé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 ne vont que dans les journaux du serveur.
• Recommandé : les notifications (webhooks) venant 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 autorisées. Rejetez tout le reste avec un message clair. N'affichez pas les détails internes des erreurs aux utilisateurs.

6. Limites de débit et abus

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

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

7. Dépendances

Les applications sont construites à partir de paquets open source, 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é : supprimez 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 tous les un ou deux mois, ou activez les alertes automatiques si votre code est sur GitHub.

8. Sauvegardes et récupération

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

• Indispensable : sachez où vivent vos données et si elles sont sauvegardées. Ne supposez rien ; vérifiez la documentation de votre hébergeur.
• Recommandé : conservez votre propre export périodique des données importantes (par exemple une fonction d'export CSV ou un export de base de données), stocké à part.
• Recommandé : conservez votre code dans un système de gestion de versions, pour pouvoir restaurer n'importe quelle version.
• Recommandé : les actions destructrices (supprimer un compte, supprimer un projet) demandent une confirmation, et envisagez une « suppression réversible » 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 la mise en ligne

• Indispensable : le site en ligne utilise HTTPS partout.
• Indispensable : les données d'exemple, les comptes de test et les pages de débogage du développement sont supprimés.
• Recommandé : une politique de confidentialité indique quelles données vous collectez et pourquoi, obligatoire dans de nombreux pays si vous collectez des données personnelles. Ne revendiquez pas de certifications (SOC 2, HIPAA) que vous n'avez pas.
• Recommandé : vous disposez d'un moyen d'être contacté au sujet des failles de sécurité, et vous savez régénérer rapidement chaque clé.

Pour une vérification plus large avant le lancement, au-delà de la sécurité, voir comment mettre un prototype IA en production.

Quand faire appel à un professionnel

Une checklist repère les erreurs courantes ; elle ne remplace pas un expert. Envisagez de payer une revue si vous traitez vous-même des numéros de carte au lieu de passer par un paiement hébergé, si vous stockez des données de santé, financières ou relatives aux enfants, si vous vendez à des entreprises qui demandent des questionnaires de sécurité, ou si une fuite vous causerait un préjudice sérieux. Avoir un code exportable facilite beaucoup une telle revue.

La sécurité lorsque l'on construit sur Mythex

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

• Secrets du projet. Stockez les clés dans Paramètres du projet → Secrets, ou via la carte des secrets que l'agent affiche dans le chat, pour qu'elles restent hors de votre code et de vos messages. Après avoir modifié un secret pour une application en ligne, publiez à nouveau.
• Modes Plan et Question. Demandez à l'agent de revoir les droits sans rien modifier : « En mode Question, listez chaque route d'API et le contrôle de droits qu'elle effectue. »
• /test fait parcourir votre aperçu par l'agent comme un utilisateur, utile pour le test à deux comptes de la section 2.
• Points de contrôle permettent d'annuler une modification qui a cassé quelque chose.

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

Questions