# Auditer la sécurité d'une base Supabase

> RLS, fonctions Security Definer, politiques de Storage : les trois endroits où une base Supabase fuit. Un audit à lancer avant chaque mise en production.

Cette skill vérifie les trois surfaces où une base Supabase expose des données sans qu'on s'en aperçoive : les tables sans Row Level Security, les fonctions Security Definer qui contournent les politiques, et les buckets Storage ouverts. Rapport avec les problèmes critiques d'abord.

**Skill :** `supabase-audit` · **Gratuit** · **Mis à jour le** 26 juillet 2026

## Installation

```bash
mkdir -p ~/.claude/skills/supabase-audit && curl -fsSL https://reversed.ch/ressources/supabase-audit.md -o ~/.claude/skills/supabase-audit/SKILL.md
```

## Lancement

```bash
/supabase-audit
```

**Ce que ça produit :** Un rapport de sécurité avec les problèmes critiques en tête

Supabase rend la mise en production très rapide, et c'est précisément le problème : la clé anonyme est publique par conception, exposée dans le navigateur. Ce qui protège vos données n'est pas le secret de cette clé, mais les politiques Row Level Security. Une table sans RLS est une table lisible par tout le monde.

## Les trois surfaces

- **RLS** : tables sans politique, ou avec des politiques trop permissives — le cas classique étant `USING (true)` laissé après un test
- **Security Definer** : les fonctions qui s'exécutent avec les droits de leur créateur et court-circuitent donc RLS. Utiles, mais chacune est une porte à justifier
- **Storage** : buckets publics, politiques d'upload absentes, chemins devinables

## La méthode derrière

L'audit ne se contente pas de vérifier que RLS est activé. Une table avec RLS activé et une politique permissive est plus dangereuse qu'une table sans RLS : le tableau de bord affiche un cadenas vert, et tout le monde arrête de regarder.

C'est le moment de le lancer qui compte : avant chaque mise en production, et après chaque changement de schéma. Une migration qui crée une table oublie presque toujours sa politique.

## Questions fréquentes

### Faut-il donner un accès à ma base ?

La skill travaille sur les migrations et le schéma présents dans votre dépôt. Un accès en lecture permet de vérifier l'état réel en production, qui diffère parfois de ce que disent les migrations.

### Est-ce que ça corrige les problèmes trouvés ?

Non, et c'est délibéré. Une politique RLS encode une règle métier : qui a le droit de voir quoi. Générer ça automatiquement produirait des politiques plausibles et fausses. La skill propose, vous tranchez.

### À quelle fréquence le relancer ?

À chaque mise en production, et systématiquement après une migration qui ajoute une table. C'est là que les oublis se produisent.

---

## Contact

- WhatsApp : +41 79 774 9793
- Email : hello@reversed.ch
- Calendly : https://calendly.com/maxdmnt/reversed
- Page web : https://reversed.ch/outils/audit-securite-supabase
- Fichier source : https://reversed.ch/ressources/supabase-audit.md