BOB_sec
Scanner mon app →
Audit sécurité · Supabase × Lovable / Bolt / v0

Votre app no-code marche.
Mais fuit-elle vos données ?

1 application indie sur 9 expose ses clés Supabase directement dans le navigateur. Je trouve la faille, je la corrige, et je vérifie que rien ne casse.

politique RLS · table : commandes
create policy "acces" on commandes
  using ( true );  ← lisible par tous
↓ corrigé
create policy "acces" on commandes
  using ( auth.uid() = client_id );
✓ SÉCURISÉ
1 / 9
applications indépendantes exposent leurs clés Supabase dans le code du navigateur.
// scan public · 20 000+ apps · 2026
≈ 4×
plus de failles critiques sur les apps Supabase que sur la moyenne — presque toujours le RLS laissé désactivé.
// rapports de scan · 2026
1,5 M
credentials et 35 000 emails fuités par une seule app IA, à cause d'un réglage de sécurité manquant.
// incident Moltbook · févr. 2026
Ce que je trouve à chaque fois

Trois failles, toujours les mêmes

Les outils IA génèrent une app qui fonctionne — mais rarement une app sécurisée. Voici les trois défauts que je retrouve dans la quasi-totalité des projets Supabase vibe-codés.

01

Table sans RLS

La clé publique est présente dans chaque page de votre site. Sans Row Level Security, n'importe qui avec cette clé peut lire, modifier ou supprimer toute la table.

rls: off
02

Clé service_role dans le frontend

Cette clé ignore toutes vos règles de sécurité. Si elle se retrouve dans le code envoyé au navigateur, c'est un accès administrateur complet à votre base, offert à tout le monde.

service_role exposée
03

Politique trop permissive

La règle existe, elle rassure — mais USING (true) autorise tout le monde. Un faux sentiment de sécurité, souvent pire que rien.

using ( true ) → auth.uid()
Cas réel

Afrika Artisana

React / TypeScript · Supabase · Docker auto-hébergé

Plateforme e-commerce pour artisans africains. J'ai conçu et sécurisé l'architecture Supabase de bout en bout — le même travail que je fais sur votre app, mais sur une plateforme entière, partie de zéro.

Je ne vends pas un discours sur la sécurité.
Je vends ce que j'ai déjà construit.

  • Politiques RLS + RBAC par rôle : client, artisan, administrateur — chacun ne voit que ses propres données.
  • Protection stricte des rôles admin : aucune élévation de privilège possible depuis le navigateur.
  • Gestion des clés : la clé service_role isolée côté serveur, jamais dans le bundle client.
  • Déploiement auto-hébergé en Docker, avec TLS et sauvegardes de la base.
Comment ça se passe

Trois étapes, sans jargon

Étape 1 · Audit

Je regarde votre app

Vous m'envoyez l'URL. Je teste chaque table, chaque clé, chaque politique. Vous recevez un rapport clair et priorisé sous 48h — ce qui est ouvert, et ce que ça risque.

Premier scan gratuit
Étape 2 · Correction

Je ferme les portes

Je réécris les politiques, j'isole les clés sensibles, je teste que votre app fonctionne exactement comme avant. Livré avec les preuves, avant / après.

Étape 3 · Surveillance

Je veille (en option)

Revue mensuelle, sauvegardes automatiques, alertes si quelque chose se rouvre. Vous vous concentrez sur votre produit, pas sur vos fuites.

B

Qui je suis

BOB — développeur full-stack & DevOps basé au Cameroun. Je travaille en Go, Kubernetes, React / TypeScript, Supabase et Docker. Je ne fais pas que corriger des bases de données : je sais construire l'application complète autour, ce qui veut dire que je comprends d'où viennent vraiment les failles.

Supabase / RLS React · TypeScript Go Kubernetes Docker Français / English
Scan gratuit · réponse sous 48h

Envoyez-moi l'URL de votre app. Je vous dis si elle fuit.

Pas de jargon, pas d'engagement. Un rapport clair sur ce qui est exposé — et vous décidez ensuite.

bobdarnauld@gmail.com · +237 69 32 44 211