Aller au contenu

Catégorie L · Créer avec l'IA · Épreuve 6 sur 8 · 5 min

Sécurité : les vérifications avant de publier

Mis à jour le

Un homme debout dans un atelier sourit en travaillant sur un ordinateur portable posé sur un établi.
Objectif · Repérer les trois failles classiques d'un site fait avec l'IA et faire, avant de publier, les vérifications qui protègent les données de tes visiteurs.Photo : javier trueba sur Unsplash

Avant de publier un site fait avec l'IA, vérifie trois choses : aucune clé secrète dans la page, des règles d'accès actives sur chaque table de la base de données, aucun fichier privé en accès libre. Puis teste avec deux comptes et sans compte, et lance l'outil de vérification de ta plateforme.

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08

Étape 1 sur 8

Les trois trous qui reviennent toujours

Les outils de création vont vite, et les mêmes failles reviennent d'un projet à l'autre :

  1. Une clé secrète visible. Tout ce qui est envoyé au navigateur peut être lu par n'importe quel visiteur, même si rien ne s'affiche à l'écran.
  2. Une base de données sans règles. Beaucoup de ces outils s'appuient sur Supabase, une base de données en ligne. Sa documentation prévient : une table exposée sans « RLS » (les règles qui disent qui peut lire et modifier quoi) peut être lue et modifiée par d'autres. La faille CVE-2025-48757, révélée en 2025, venait justement de là : plus de 170 projets Lovable laissaient lire leurs données faute de règles.
  3. Des fichiers en accès libre : factures, pièces d'identité, photos rangées dans un dossier public.

Supabase donne une image parlante de ses deux clés : la clé publique est scotchée sur la porte d'entrée et n'ouvre que le hall ; ce sont les règles RLS qui gardent les étages. La clé secrète est le passe-partout : elle contourne toutes les règles et ne doit jamais quitter ton serveur.

Relie chaque élément à la bonne règle.

Touche un élément à gauche, puis celui qui va avec à droite.

La liste de contrôle avant d'ouvrir

Avant de donner le lien à qui que ce soit, prends vingt minutes :

  • Deux comptes de test. Crée « Test A » et « Test B ». Ce que A enregistre, B ne doit jamais le voir, même en changeant l'adresse dans la barre du navigateur.
  • Sans compte. Ouvre le site en navigation privée : rien de privé ne doit apparaître.
  • Les règles RLS activées sur chaque table, comme le demande Supabase.
  • Aucun secret dans la conversation. Sites, chez OpenAI, demande de garder les valeurs secrètes hors des demandes, des fichiers joints et du contenu du site, et de les ranger dans les réglages prévus.
  • L'outil de vérification de ta plateforme. Chez Bolt, le bouton « Run security audit » du menu Publish (offres payantes) ne consomme aucun jeton, alors que demander un audit par écrit en consomme ; un contrôle de la base existe aussi en gratuit.

Un piège à connaître, rappelé par OpenAI : un bouton masqué n'est pas une protection. Si le bouton « Supprimer » est seulement masqué, quelqu'un peut quand même envoyer la demande. La protection doit être appliquée par le serveur.

Yanis a créé un carnet d'adresses en ligne pour son club de randonnée. Quel test prouve le mieux que les données sont protégées ?

Vrai ou faux ?

Masquer le bouton « Supprimer » aux visiteurs suffit à les empêcher de supprimer des données.

Les données de tes clients

Dès que ton site garde des noms, des e-mails ou des commandes, tu es responsable de ces données au sens du RGPD. Trois réflexes :

  • Ne collecte que l'utile. Pas de date de naissance si un prénom suffit. Ce que tu n'as pas ne peut pas fuir.
  • Protège les accès à tes comptes d'outils (création, base de données, hébergeur) : un mot de passe différent pour chacun et la double authentification, comme le conseille la CNIL.
  • Si une fuite arrive : change immédiatement les clés concernées, puis évalue le risque. Selon la CNIL, une fuite qui présente un risque pour les personnes doit lui être notifiée, et les personnes doivent être prévenues si le risque est élevé. En cas de doute, notifie : la CNIL te dira s'il faut informer les personnes.

Si tu as installé n8n sur ton propre serveur, fais ses mises à jour : une faille rendue publique en janvier 2026, corrigée en version 1.121.0, permettait à un inconnu de lire des fichiers du serveur à travers certains formulaires.

Sur Supabase, la clé …… contourne toutes les règles RLS : elle ne doit jamais quitter ton serveur.

Ce que l'IA ne te dira pas

En janvier 2026, SupaExplorer a passé au crible plus de 20 000 sites lancés par des indépendants : environ 1 sur 9 laissait voir dans ses pages ses accès à Supabase, avec plus de 2 300 cas jugés graves. Un piège revient souvent : les outils placent dans la page toute variable dont le nom commence par VITE_, NEXT_PUBLIC_ ou PUBLIC_. Une clé secrète ne doit jamais porter ces préfixes.

Source : SupaExplorer, « State of Supabase Exposure Across Vibe-Coding Apps » (janvier 2026)

Sources