C'est pour qui ?
Pour toute personne qui a construit une app avec l'IA et qui est sur le point de la publier — pas besoin de savoir programmer. Si ton app enregistre des données d'utilisateurs (comptes, messages, commandes, peu importe), c'est obligatoire avant de la mettre en ligne. Chaque section propose une analogie, le risque, et un prompt pour que ton IA le configure. Toi, tu n'as qu'à approuver.
Quand fait-on ça ? (le moment exact)
Le moment est clair et non négociable : juste avant de publier ton app ou de la donner à de vrais utilisateurs. Tant que tu testes tout seul sur ton ordinateur, il ne se passe rien. Mais à la seconde où ton app est en ligne avec les données d'autres personnes, sans ces verrous, tu exposes tout. Et comme l'IA ne le fait pas d'elle-même (elle pense à faire fonctionner, pas à protéger), c'est à toi de le demander explicitement.
La douleur qui a donné naissance à ce guide
C'est la pire frayeur de celui qui construit avec l'IA : tu lances ton app, quelqu'un change un chiffre dans l'URL… et voit les données d'un AUTRE utilisateur. Ou pire : une faille de sécurité expose toute ta base de données. Ça ne se ressent pas à la construction — tout « fonctionne » — mais c'est une bombe à retardement. Ces 3 verrous la désamorcent en quelques minutes.
Verrou 1 · RLS (que chacun ne voie QUE ce qui lui appartient)
Imagine ça comme ça
Imagine un coffre à jouets géant où tout le monde range ses affaires. Sans cadenas, n'importe qui attrape les affaires de tout le monde. RLS (Row-Level Security, « sécurité au niveau de la ligne ») est un cadenas magique qui sait qui est qui : chaque utilisateur ne voit et ne touche que ses propres données, même si tout est dans le même coffre.
Sans RLS, un utilisateur malveillant n'a qu'à changer un ID dans l'URL ou dans une requête pour voir les données de quelqu'un d'autre. C'est la vulnérabilité la plus courante dans les apps avec Supabase et PostgreSQL — et la plus facile à exploiter. C'est pour ça que c'est le verrou n°1.
J'utilise Supabase avec PostgreSQL. J'ai ces tables : [liste tes tables et leurs colonnes d'utilisateur, ex : posts (user_id), comments (post_id, user_id)]. Configure Row-Level Security pour que chaque utilisateur ne puisse voir/modifier/supprimer que ses propres enregistrements. Suis les meilleures pratiques officielles de Supabase : - Active RLS sur TOUTES les tables (ENABLE ROW LEVEL SECURITY). - Crée des politiques SÉPARÉES pour SELECT, INSERT, UPDATE et DELETE (N'utilise PAS FOR ALL). - IMPORTANT pour la performance : enveloppe la fonction d'utilisateur comme (SELECT auth.uid()), PAS auth.uid() seul, pour que Postgres l'évalue une seule fois par requête et non une fois par ligne. - Restreins les politiques au rôle authenticated (TO authenticated), pas à public, pour que les visiteurs anonymes ne touchent même pas la table. - N'utilise JAMAIS user_metadata dans les politiques (l'utilisateur peut le modifier). - Ajoute des index sur les colonnes utilisées par les politiques (ex. user_id). - Rappelle-toi : pour qu'un UPDATE fonctionne, il faut aussi une politique de SELECT. - Donne-moi le SQL complet prêt à coller dans le SQL Editor de Supabase, et explique-moi en une ligne ce que fait chaque politique.
L'erreur qui rend ton app ultra-lente (le « init-plan trap »)
Presque tous les tutoriels te disent d'utiliser
auth.uid() directement dans la politique. MAIS ça fait que Postgres l'évalue une fois par ligne — dans une table de 100 000 lignes, la différence est entre une requête de 5 millisecondes et une de 5 secondes ! L'astuce (documentée par Supabase) : écris-le comme `(SELECT auth.uid())`. Ainsi il n'est évalué qu'une seule fois. C'est pour ça que le prompt ci-dessus le demande explicitement.Comment savoir que ça marche déjà ?
- Crée deux utilisateurs de test dans ton app.
- Connecte-toi avec l'utilisateur A et crée un enregistrement.
- Connecte-toi avec l'utilisateur B : il ne doit PAS voir l'enregistrement de A.
- Consulte le Security Advisor de Supabase : il te prévient si tu as laissé une table sans RLS.
Verrou 2 · CORS (qui peut appeler ton API)
Imagine ça comme ça
CORS est le portier de ton API. Il décide quelles pages web ont le droit de frapper à la porte. Sans portier, n'importe quel site du monde peut appeler ton backend depuis le navigateur de tes utilisateurs et profiter de leur session.
Configure CORS sur mon backend pour que SEUL mon domaine de production (https://mon-app.com) et localhost en développement puissent faire des requêtes. - N'utilise PAS "*" comme origine autorisée en production. - N'autorise que les méthodes que j'utilise vraiment (ex. GET, POST, PUT, DELETE). - N'autorise que les en-têtes dont j'ai besoin. - Explique-moi exactement où mettre chaque chose selon ma stack : [dis-moi ton framework/backend].
Erreur à ne JAMAIS commettre
Laisser
Access-Control-Allow-Origin: * avec les credentials activés. C'est comme laisser la porte ouverte et poser une pancarte qui dit « entrez, j'ai laissé les clés à l'intérieur ». Si ton IA te l'a configuré comme ça « pour que ça marche vite », corrige-le avant de publier.Verrou 3 · Security Headers (consignes de défense au navigateur)
Imagine ça comme ça
Les headers de sécurité sont les règles de la maison que ton site donne au navigateur en arrivant : « ne me mets pas dans un cadre d'un autre site », « ne charge pas de scripts de sites que je n'ai pas autorisés », « parle-moi seulement par connexion sécurisée ». Sans ces règles, le navigateur fait n'importe quoi — et ça ouvre la porte aux attaques courantes.
Ajoute les headers de sécurité recommandés à mon app : Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security (HSTS) et Permissions-Policy. - Explique-moi ce que fait chacun en une ligne simple. - Donne-moi la configuration prête pour mon framework : [dis-moi lequel tu utilises, ex. Next.js, Express]. - Commence la Content-Security-Policy en mode report-only pour ne rien casser, et dis-moi comment la durcir ensuite. - Dis-moi comment vérifier le résultat.
Vérifie ta note gratuitement
Après les avoir configurés, colle l'URL de ton site dans securityheaders.com et il te donne une note de A+ à F. C'est le moyen le plus rapide de confirmer qu'ils sont bien en place — vise un A.
L'habitude · vérifie-le avant chaque publication
Ta checklist de sécurité pré-lancement
- RLS activé sur toutes les tables avec des données d'utilisateurs (et testé avec 2 comptes).
- CORS restreint à tes domaines, jamais
*avec credentials. - Headers en place et avec une note A sur securityheaders.com.
- Tes secrets (.env, clés d'API) JAMAIS envoyés sur GitHub (voir le guide GitHub de la série).
- Tu as consulté le Security Advisor de Supabase et il ne reste aucun avertissement en rouge.
Combine-le avec le C-A-R
La sécurité est justement le genre de chose que le mode constructeur de l'IA laisse passer. C'est pour ça que ça s'intègre parfaitement dans la phase d'audit du [protocole C-A-R](/recursos/protocolo-car-construir-sin-bugs) : quand tu audites avant de publier, ajoute ces 3 verrous à la liste. Construire pense à faire fonctionner ; auditer pense à comment on l'attaque.
Sur NeuralOS, la sécurité est là dès le départ
Sur NeuralOS, les apps que tu construis naissent avec ces protections activées par défaut — RLS, origines restreintes et headers — sans que tu aies besoin de penser à les configurer. L'idée est que tu ne puisses pas publier quelque chose de non sécurisé par oubli. La vision est déjà sur le chemin que nous construisons.