Le Vibe Code Security Kit
N'importe qui peut voir des données qu'il ne devrait pas voir, pas seulement via votre base de données. Des clés API exposées, des vérifications d'autorisation manquantes et des flux d'authentification cassés sont tout aussi fréquents. Voici tous les prompts qu'on utilise en revue payante pour tous les détecter, quelle que soit votre stack.
Dès 29 € · Livraison immédiate · Aucun compte requis · Fonctionne sur toute stack (Supabase, Firebase, PlanetScale, ou votre propre backend)
Conçu pour les développeurs qui ont shippé vite et sauté l'audit.
Vous avez shippé une app
Elle fonctionne, elle est en ligne, et vous n'avez rien vérifié sous le capot depuis que l'IA l'a écrite.
Vous avez de vrais utilisateurs
Des gens s'inscrivent, stockent des données, vous paient. Une fuite n'est plus hypothétique.
Vous l'avez construite avec des outils IA
Lovable, Bolt, v0, Cursor ou Claude Code ont écrit l'essentiel du backend. Vous avez relu l'interface, pas les règles d'accès.
5 catégories de failles. 14 prompts. Pas seulement votre base de données.
Les mêmes catégories qu'on vérifie en revue payante, pour que vous reconnaissiez votre propre risque avant même de voir un prix.
Clés & secrets exposés
Des clés API envoyées au navigateur, des clés service-role avec plus d'accès que nécessaire côté client, et des variables d'environnement qui fuitent dans votre bundle JavaScript.
Exemple de faille trouvée
Une clé service-role Supabase s'est retrouvée dans le JavaScript côté client d'une app en production, donnant un accès complet en lecture/écriture à la base à quiconque ouvrait les outils de développement.
Contrôle d'accès
Deux prompts dédiés : IDOR Audit (repère chaque endroit où un ID de ressource est fait confiance depuis l'URL sans vérifier que l'utilisateur courant y a droit) et Admin Route Audit (repère chaque route /admin, /dashboard ou /internal sans vérification de rôle, pas juste de connexion), plus un balayage général des autorisations manquantes sur vos routes API.
Exemple de faille trouvée
Un bucket de stockage de documents était accessible à quiconque devinait l'URL : pas de connexion, pas de vérification de propriétaire, juste un nom de fichier prévisible.
Base de données
Une row-level security absente, mal configurée, ou techniquement présente mais contournable, ainsi que des vues SQL qui exposent plus que prévu.
Exemple de faille trouvée
La row-level security était activée sur une table orders mais aucune policy n'y était attachée, ce qui autorise par défaut tout utilisateur connecté à lire les commandes de tous les clients.
Authentification
Une gestion de session faible, aucune limitation de tentatives sur la connexion ou la réinitialisation de mot de passe, et des flux OAuth ou JWT implémentés de façon à fuiter ou mal gérer les tokens.
Exemple de faille trouvée
Un JWT était transmis en paramètre d'URL plutôt qu'en en-tête sécurisé, et s'est retrouvé enregistré en clair dans les logs serveur et l'historique de navigation.
Entrées & webhooks
Des entrées non validées qui ouvrent la porte à l'injection, et des endpoints de webhook qui ne vérifient pas qui les appelle réellement.
Exemple de faille trouvée
Un endpoint de webhook Stripe acceptait les requêtes sans vérifier la signature, permettant à quiconque trouvait l'URL de simuler un événement « paiement réussi ».
Avant / après
create policy "documents_all"
on public.documents
for all
using ( true );Une policy USING (true) unique a l'air de marcher, mais laisse n'importe qui lire ou écrire n'importe quelle ligne.
create policy "documents_select_own"
on public.documents
for select
to authenticated
using ( (select auth.uid()) = user_id );
create policy "documents_update_own"
on public.documents
for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );Scopée à l'utilisateur courant, avec WITH CHECK pour l'empêcher de réassigner des lignes à quelqu'un d'autre.
Les mêmes failles qu'on trouve en revue payante, sur des apps construites avec des outils IA.
Résultats anonymisés d'audits Validra réels, le genre de chose que les prompts du Kit sont conçus pour détecter.
RLS absente sur la table orders
La row-level security était activée sur la table orders mais aucune policy n'y était attachée, ce qui autorise par défaut l'accès complet à tout utilisateur authentifié.
Impact
N'importe quel utilisateur connecté pouvait lire les commandes, adresses et montants de tous les clients.
Clé service-role envoyée au navigateur
Une clé service-role Supabase a été assignée à une variable sans passer par la convention de préfixe NEXT_PUBLIC_, et s'est retrouvée dans le JavaScript côté client.
Impact
Accès complet en lecture/écriture à la base, contournant totalement la RLS, exposé à n'importe quel visiteur du site.
Bucket de stockage public avec des fichiers utilisateurs
Un bucket d'uploads a été laissé public par commodité pendant le développement et jamais verrouillé avant le lancement.
Impact
Les documents et images uploadés par les utilisateurs étaient listables et téléchargeables par quiconque connaissait l'URL du bucket.
Résultats anonymisés. Trace d'audit complète disponible sur demande.
Trois façons de l'obtenir.
Pas d'abonnement, pas de compte. Paiement unique, livraison immédiate.
Starter
Les 14 prompts d'audit couvrant les 5 catégories.
- 14 prompts d'audit couvrant clés & secrets, contrôle d'accès, base de données, authentification et validation des entrées. À coller dans Cursor, Claude Code ou votre outil IA préféré, et à exécuter en quelques minutes
- Inclut les prompts IDOR Audit et Admin Route Audit
- Compatible avec tout assistant de code IA : Cursor, Claude Code, Copilot ou autre
- Fonctionne sur toute stack : Supabase, Firebase, PlanetScale ou un simple backend Node
Core
Starter, plus les modèles et scripts pour prouver que vos correctifs fonctionnent vraiment.
- Tout Starter (14 prompts, 5 catégories)
- 8 modèles de policies (RLS et patterns de contrôle d'accès équivalents), prêts à copier-coller
- Scripts de vérification SQL qui prouvent, preuve à l'appui, si un utilisateur peut lire les données d'un autre
- Conçu pour les stacks basées sur Postgres ; les 14 prompts s'appliquent quant à eux à toute stack
Complete
Core, plus la checklist de sécurité complète et un accompagnement avec le fondateur.
- Tout Core (14 prompts, 8 modèles de policies, scripts SQL)
- Checklist des 25 failles les plus fréquentes, à exécuter à tout moment, pas juste une fois
- Guide de durcissement : le raisonnement derrière chaque correctif, pour que votre équipe arrête de reproduire les mêmes erreurs
- Vidéo Loom de 20 minutes, enregistrée par Téo, qui montre exactement comment utiliser le kit sur une vraie app
Pourquoi ne pas juste demander à ChatGPT ?
Vous pouvez. Des prompts génériques sur les « bonnes pratiques de sécurité » vous donneront des réponses génériques sur le hachage de mot de passe et HTTPS, vrai, mais pas ce qui casse les apps construites par IA. Ces prompts sont volontairement précis : ils ciblent les modes de défaillance qu'on retrouve encore et encore dans le contrôle d'accès, les clés exposées, les policies de base de données et les webhooks construits par des outils de code IA. Cette précision, c'est le produit.
Des questions avant d'acheter.
Et si je ne suis pas satisfait ?
Écrivez-moi dans les 14 jours et je vous rembourse, sans question.
Comment est-ce livré ?
Un lien vers une page privée avec tout ce qui est inclus dans votre palier, plus un PDF téléchargeable, envoyé par email juste après le paiement.
Quelles stacks sont supportées ?
Les prompts fonctionnent avec n'importe quel assistant IA sur n'importe quelle stack : Supabase, Firebase, PlanetScale ou un simple backend Node. Les modèles de policies de contrôle d'accès inclus dans Core et Complete sont écrits pour les stacks basées sur Postgres (Supabase et équivalents) ; le reste du kit s'applique partout.
Quel niveau technique faut-il ?
Vous devez être à l'aise pour coller un prompt dans votre assistant de code IA, et à l'aise pour exécuter du SQL sur votre base si vous choisissez Core ou Complete. Si vous avez shippé une app, vous avez déjà les deux compétences.
Quelle différence avec une revue Validra ?
Le Kit vous dit où regarder et vous donne les outils. Une revue Validra, c'est nous qui regardons réellement : tests manuels, tentatives d'accès inter-comptes, et un rapport écrit que vous pouvez montrer à un investisseur ou un client.
Si vous préférez qu'on fasse l'audit pour vous, réservez une Revue de sécurité.
Mêmes catégories, faites à la main, avec un rapport exploitable en une journée.