La ressource précédente t'a donné les 3 serrures indispensables avant de publier. Voici le niveau suivant : le blindage qu'utilisent les produits sérieux. Commençons par une vérité inconfortable et libératrice : rien n'est « impénétrable ». Google, Stripe, les banques — tous peuvent être attaqués. Le vrai but n'est pas d'être invulnérable ; c'est d'être si coûteux et si pénible à attaquer que l'attaquant abandonne et cherche une proie plus facile, et de contenir les dégâts quand quelque chose arrive pour qu'une faille ne devienne pas une catastrophe. C'est comme ta maison : celle qui est impossible à cambrioler n'existe pas, celle qui a des grilles, une alarme, un chien et des caméras existe — celle où le voleur regarde, calcule l'effort, et va chez le voisin. Voilà le but : être la maison difficile. Voici les 8 couches qui y parviennent, en langage simple, chacune avec son analogie et un prompt pour la demander à ton IA.
Rien n'est « impénétrable », et quiconque te dit le contraire te ment. Google, Stripe, les banques : tous peuvent être attaqués. Alors, à quoi sert la sécurité ? Le vrai but n'est pas d'être invulnérable — c'est d'être si coûteux et si pénible à attaquer que l'attaquant abandonne et cherche une proie plus facile. Et c'est de contenir les dégâts quand quelque chose arrive, pour qu'une faille ne devienne pas une catastrophe.
Deux choses que les gens confondent : l'authentification c'est « es-tu bien celui que tu prétends être ? » (le login), et l'autorisation c'est « as-tu la permission pour CECI en particulier ? » (cet utilisateur peut-il voir cette donnée ?). La règle d'or : refuser par défaut. Tout est fermé sauf ce qui est explicitement ouvert — jamais l'inverse. La plupart des fuites arrivent parce que quelqu'un a laissé quelque chose « ouvert par défaut » et a oublié de le fermer.
Je veux sécuriser l'authentification et l'autorisation de mon backend avec la règle « refuser par défaut ». Chaque endpoint doit naître fermé et ne s'ouvrir qu'avec une justification explicite. Configure un guard global qui exige l'authentification partout, et permets de marquer comme public seulement ce que j'indique. Pour l'autorisation, vérifie les permissions par action, pas seulement par login. Explique-moi en étapes simples ce que tu as fait.
Cette couche est exactement ce qu'on a vu dans le guide précédent (la Serrure 1). Ici on l'élève au rang de règle d'architecture : dans un produit multi-utilisateur, la RLS n'est pas optionnelle, c'est la fondation.
Mon app est multi-utilisateur (beaucoup de clients dans la même base de données). Assure l'isolation totale avec Row Level Security : active la RLS sur TOUTES les tables contenant des données d'utilisateurs, avec des policies qui garantissent que chacun n'accède qu'à ce qui est à lui. Je veux que la base l'impose même si le code a un bug. Utilise (SELECT auth.uid()) pour la performance et restreins au rôle authenticated. Donne-moi le SQL et explique-moi comment tester qu'un utilisateur NE PEUT PAS voir les données d'un autre.
Ajoute du rate limiting à mon backend : une limite de requêtes par minute par utilisateur et par IP, plus stricte sur les endpoints sensibles (login, inscription, et ceux qui appellent l'IA). Quand la limite est dépassée, réponds avec une erreur claire (429) sans faire tomber le serveur. Dis-moi les limites que tu recommandes pour commencer et comment les ajuster.
Avant qu'une requête malveillante ne touche ton serveur, elle passe par un bouclier extérieur — Cloudflare est le standard. Ce bouclier absorbe les attaques massives (les DDoS : des milliers de machines qui t'attaquent en même temps), filtre les bots connus et bloque les schémas d'attaque. Ton serveur reste caché derrière, sans exposer ses portes directement. C'est la première ligne, celle qu'utilisent les grands.
Je veux mettre un bouclier extérieur (WAF/CDN comme Cloudflare) devant mon app. Guide-moi en étapes simples pour : faire passer mon domaine par Cloudflare, activer la protection DDoS et le firewall applicatif, et cacher mon serveur d'origine pour que personne ne le frappe directement. Dis-moi quelles configurations activer d'entrée et lesquelles sont gratuites.
Sécurise mes secrets (API keys, mots de passe, tokens). 1) Sors-les du code et de git : mets-les dans des variables d'environnement et crée un .gitignore qui ignore .env. 2) Si je stocke des clés de mes utilisateurs, chiffre-les dans la base avec une clé par utilisateur. 3) Configure gitleaks comme hook avant chaque commit pour qu'il me bloque si je tente de pousser un secret par accident. Explique-moi chaque étape en simple.
Ne fais jamais confiance à ce que l'utilisateur envoie. Chaque donnée qui arrive à ton backend est validée contre un schéma strict avant de toucher quoi que ce soit. Cela bloque les attaques classiques : le SQL injection (que l'attaquant glisse des commandes dans un formulaire pour voler ta base de données), l'injection de prompts (qu'un utilisateur manipule ton IA pour qu'elle contourne ses règles), et les données malformées qui cassent le système. La règle : valider à chaque bord. Tout ce qui est externe est suspect jusqu'à preuve du contraire.
Valide TOUTE l'entrée de mon backend avec un schéma strict (utilise Zod ou équivalent) sur chaque endpoint, avant de traiter quoi que ce soit. Rejette ce qui ne respecte pas le schéma. Protège-moi spécifiquement contre le SQL injection, l'injection de prompts à l'IA, et les données malformées. Donne-moi le pattern pour l'appliquer à chaque bord et un exemple sur l'un de mes endpoints.
Mon app utilise l'IA (qui coûte de l'argent à l'usage). Protège-moi qu'un utilisateur ne me saigne les crédits : 1) mets à chaque utilisateur un budget/limite quotidien d'usage de l'IA, et coupe-le quand il l'atteint avec un message clair. 2) Enregistre la consommation par utilisateur pour détecter les comportements anormaux. 3) Préviens-moi si quelqu'un fait exploser sa dépense. Explique-moi comment définir les limites pour ne pas affecter l'utilisateur normal.
Tu ne peux pas protéger ce que tu ne vois pas. Chaque action importante est enregistrée (qui, quoi, quand) dans un log immuable que personne ne peut effacer. S'il se passe quelque chose d'étrange, tu as l'enregistrement. Et un système d'alertes te prévient pendant que ça arrive, pas après. C'est ce qui te laisse dormir tranquille : si quelqu'un tente quelque chose, tu le vois en direct.
Ajoute de l'audit et de l'observabilité à mon app : 1) un log immuable qui enregistre qui a fait quoi et quand dans les actions importantes (login, changements de données, paiements), qui ne puisse être ni effacé ni modifié. 2) Des alertes qui me préviennent en temps réel s'il se passe quelque chose de suspect (beaucoup de tentatives de login échouées, dépense anormale, erreurs en pics). Dis-moi quels événements enregistrer en premier et comment recevoir les alertes.
Si tu veux toutes les demander ensemble au démarrage d'un projet sérieux, ce prompt résume les 8 couches pour que ton IA les prenne en compte dès la fondation :
Nous allons construire ce backend avec une sécurité de niveau enterprise dès le jour 1, en utilisant la « défense en profondeur » (beaucoup de couches). Prends en compte ces 8 couches dans tout ce que tu construis, et rappelle-moi laquelle manque : 1. AUTH : authentification + autorisation avec « refuser par défaut » (tout fermé sauf ce que j'ouvre explicitement). 2. ISOLATION : Row Level Security sur toutes les tables (chaque utilisateur ne voit que ce qui est à lui, imposé par la base). 3. RATE LIMITING : limite de requêtes par utilisateur/IP, plus stricte sur les endpoints sensibles. 4. BOUCLIER EXTÉRIEUR : WAF/CDN (Cloudflare) devant, avec protection DDoS et l'origine cachée. 5. SECRETS : pas de clés dans le code/git ; vault + variables d'environnement ; clés d'utilisateur chiffrées ; gitleaks avant chaque commit. 6. VALIDATION : valider toute entrée avec un schéma strict (Zod) à chaque bord ; protection contre le SQL injection et l'injection de prompts. 7. COST GUARDRAILS : budget d'IA par utilisateur avec coupure automatique ; détecter la consommation anormale. 8. AUDIT : log immuable (qui/quoi/quand) + alertes en temps réel. Commence par me dire lesquelles s'appliquent à mon projet et dans quel ordre nous les implémentons, sans sur-ingénierie pour ce dont je n'ai pas encore besoin.
Join 4,200+ builders. No credit card. Build your first app with AI in minutes.