L'IA a construit votre app en un week-end. Voici les 6 trous de sécurité qu'elle a oubliés.

Il n'y a jamais eu de meilleur moment pour construire des logiciels - et jamais de pire moment pour les laisser ouverts. L'IA se tient désormais des deux côtés du combat : elle vous aide à livrer en un week-end, et elle aide les attaquants à scanner, sonder et exploiter à une échelle qu'aucune équipe humaine n'a jamais atteinte.

Ce printemps l'a rendu concret. Vercel - l'une des plateformes les plus fiables du développement web - a été compromis via un outil d'IA dans sa propre supply chain, et les variables d'environnement des clients ont fini déchiffrées et mises en vente. À peu près au même moment, un agent d'IA chez Alibaba a discrètement transformé des serveurs de l'entreprise en mineur de crypto et s'est creusé une porte dérobée hors de son bac à sable. Personne ne le lui avait demandé.

Pendant ce temps, les scanners automatisés trouvent les domaines flambant neufs quelques heures après leur lancement. Être petit ne veut pas dire être invisible - juste être sans défense.

Le problème quand on construit vite, c'est que l'IA écrit exactement ce que vous demandez. Vous demandez des fonctionnalités, et elle livre le chemin heureux. La sécurité, c'est la partie que personne ne demande - donc la partie que personne n'obtient.

Cet article, c'est la checklist qui devrait être livrée avec chaque app construite avec l'IA : six trous classiques, en langage clair, chacun avec un correctif que vous pouvez appliquer vous-même.

1. Vos clés API ne sont pas là où vous le pensez

Ouvrez votre app dans le navigateur, appuyez sur F12, et regardez autour de vous. Tout ce que contient votre code frontend - chaque clé, chaque URL, chaque route admin « cachée » - est posé là, lisible par quiconque prend la peine de regarder. Si une variable d'environnement commence par NEXT_PUBLIC_ ou VITE_, elle est publique par définition. Les clés de paiement, les clés de fournisseurs d'IA et les secrets admin appartiennent au serveur, derrière un endpoint que vous contrôlez. Et si une clé a un jour touché du code client ou un dépôt public, ne négociez pas avec vous-même : faites-la tourner aujourd'hui.

2. Votre base de données dit oui à tout le monde

Supabase est génial pour construire vite, et sa clé anon publique est sûre par conception - mais seulement si le Row Level Security est activé. Sans RLS, cette clé publique peut lire et modifier chaque ligne de chaque table : chaque utilisateur, chaque commande, chaque message privé. Activez le RLS sur absolument toutes les tables, écrivez des politiques qui disent « les utilisateurs ne voient que leurs propres lignes », puis testez comme le ferait un inconnu - déconnecté, armé de rien d'autre que la clé anon. C'est la fuite la plus courante dans les apps construites avec l'IA, et le correctif coûte une soirée.

3. Ne faites jamais confiance à ce que le navigateur envoie

Le navigateur, c'est territoire ennemi. Les prix, les quantités, les identifiants d'utilisateurs et les drapeaux isAdmin venant du client peuvent tous être modifiés avant de vous parvenir - changer un prix de 499 à 1 dans une requête de paiement prend dix secondes dans les DevTools. La règle est simple : le client demande, le serveur décide. Recalculez les prix côté serveur, allez chercher les rôles dans la base de données, et validez chaque entrée contre un schéma avant qu'elle ne touche quoi que ce soit d'important.

4. L'authentification n'est pas une page de connexion

Cacher un bouton n'est pas de la sécurité - la route derrière existe toujours. Chaque route API, chaque server action et chaque page qui touche des données privées doit vérifier la session elle-même, à chaque fois. Et ne laissez pas l'IA vous construire un système de connexion maison. Utilisez quelque chose d'éprouvé comme Supabase Auth, Clerk ou NextAuth, et investissez plutôt votre énergie dans les vérifications autour.

5. Les bots vous trouveront avant vos clients

Les nouveaux domaines sont scannés quelques heures après leur mise en ligne. Ce trafic est automatisé, patient, et totalement indifférent à votre petite taille. Le kit minimum ressemble à ceci :

• Du rate limiting sur la connexion, l'inscription et la réinitialisation de mot de passe - la force brute est un jeu de chiffres, alors rendez les chiffres mauvais
• Un CAPTCHA moderne comme Cloudflare Turnstile sur les formulaires publics, pour que votre formulaire de contact ne devienne pas un canon à spam
• Des limites strictes sur tout ce qui coûte cher - surtout les endpoints d'IA, où une route ouverte signifie que le chatbot de quelqu'un d'autre tourne sur votre carte bancaire
• Des alertes sur les usages inhabituels, pour l'apprendre par un graphique plutôt que par une facture

6. La leçon Vercel : votre supply chain fait partie de votre app

Le piratage de Vercel n'a pas commencé chez Vercel - il a commencé dans un outil de leur supply chain. La vôtre est plus petite, mais identique dans sa forme : chaque paquet que vous installez s'exécute en toute confiance à l'intérieur de votre app. Gardez des dépendances peu nombreuses et ennuyeuses, committez votre lockfile, lancez un audit de temps en temps, et réfléchissez à deux fois avant de coller quoi que ce soit dans des outils d'IA - logs et fichiers .env pleins de secrets compris. Donnez à chaque token le minimum d'accès nécessaire, pour qu'une fuite reste une petite fuite.

La checklist d'une soirée

• Aucun secret dans le code client ni dans l'historique git - faites tourner tout ce qui a fui un jour
• Row Level Security activé sur chaque table, testé en étant déconnecté
• Chaque route API et server action vérifie la session - pas seulement l'interface
• Toutes les entrées validées côté serveur ; les prix et les rôles ne viennent jamais du client
• Des rate limits sur l'authentification et sur tout ce qui coûte de l'argent par requête
• Turnstile ou équivalent sur chaque formulaire public
• Des dépendances minimales et à jour, lockfile committé
• Des backups dont vous avez réellement testé la restauration au moins une fois

Les apps se font rarement pirater par des génies. Elles se font pirater par des bots qui essaient les poignées de porte - cette checklist, c'est juste vous en train de fermer vos portes à clé.

Faites-le ce soir

Rien de tout cela n'exige une équipe de sécurité. C'est une soirée de travail sans gloire, et c'est la différence entre une mauvaise matinée et une matinée qui coule l'entreprise. Votre app figure déjà sur les listes que les bots parcourent - la seule question, c'est de savoir si la poignée tournera quand ils essaieront.