Configurer un proxy léger avec Next.js Server Actions et Supabase
De l'API externe à la base de données : le cas Supabase
Dans la leçon précédente, nous avons vu comment protéger une clé d'API tierce (comme notre widget météo) grâce à une Server Action. Mais dans une vraie application en vibe coding, vous n'allez pas seulement afficher la météo : vous allez vouloir enregistrer des utilisateurs, des listes de tâches, des commandes ou des messages privés.
Pour cela, tous les assistants IA modernes (Cursor, Bolt.new, Lovable, v0) vous suggèrent immédiatement d'utiliser Supabase. Supabase est une plateforme qui héberge votre base de données PostgreSQL dans le cloud et fournit des fonctions prêtes à l'emploi.
Mais attention : manipuler une base de données change complètement d'échelle de risque. Si votre clé météo fuite, vous risquez une surconsommation de crédits. Si la clé maîtresse de votre base de données fuite, c'est la totalité des données personnelles de vos utilisateurs qui est pillée en quelques secondes.
Comprendre Supabase avec la métaphore de l'hôtel : anon vs service_role
Pour comprendre la sécurité de Supabase sans vous perdre dans le jargon technique, visualisez un grand hôtel :
1. La clé anon = La carte magnétique du client
C'est la clé publique fournie par Supabase. Elle est faite pour être présente dans le navigateur de l'internaute. Elle permet au client d'entrer dans le hall de l'hôtel, mais elle n'ouvre que la porte de sa propre chambre. Qui l'empêche d'entrer dans la chambre du voisin ? Le vigile de l'hôtel : le RLS (Row Level Security). Si le RLS est bien activé, un visiteur malveillant muni de cette clé ne verra que ses propres données.
2. La clé service_role = Le passe-partout général de la direction
Cette clé possède les pleins pouvoirs : elle ignore (bypass) totalement le vigile RLS. Elle ouvre toutes les portes, tous les coffres et toutes les chambres. Elle est réservée aux opérations de maintenance interne sur votre serveur privé (dans une Server Action avec process.env.SUPABASE_SERVICE_ROLE_KEY).
🚨 Le piège n°1 de l'IA :
Lorsque votre application bloque une requête parce que le RLS refuse l'accès, l'agent IA a souvent la mauvaise idée de remplacer la clé anon par la clé service_role directement dans votre composant client React pour que « l'erreur disparaisse ». Cela revient à poser le passe-partout général sur le trottoir devant l'hôtel : n'importe qui ouvrant l'inspecteur web peut alors vider toute votre base de données.
Contenu premium
Abonnez-vous ou achetez la formation pour accéder à l'intégralité du contenu.
- Accès illimité à 1700 formations
Je m'abonne
Les pièges de l'IA et la sécurité des clés
Cacher ses clés avec un proxy backend
Cadrer son éditeur et auditer son code
Je m'abonne
