Étude de cas : un paywall Supabase contourné en deux requêtes

Chiffres clés

Que s'est-il passé exactement sur cette plateforme ?

Une plateforme d'éducation crypto par abonnement a laissé n'importe quel visiteur lire son contenu réservé aux membres. Le contournement tenait en deux requêtes : créer un compte gratuit, puis interroger la table de contenu avec le jeton obtenu.

Le cadre compte. C'était un audit externe et passif, réalisé début 2026 sans mandat écrit ni mission payée, sur des éléments accessibles publiquement. Aucune intrusion, aucune exploitation au-delà de la confirmation de lisibilité, aucune donnée téléchargée. Pour comparer l'accès anonyme et l'accès connecté, un seul compte de test gratuit a été créé avec une adresse générique, puis déconnecté et son jeton invalidé à la fin. Les résultats ont ensuite été transmis au propriétaire dans le cadre d'une divulgation responsable, avec la liste des corrections à faire et le compte de test à supprimer.

Cette étude de cas est anonymisée : la plateforme, ses dirigeants et son domaine restent dans l'ombre. Le schéma, lui, est très courant sur les applications construites avec Supabase.

Pourquoi une page de capture d'e-mails débloque-t-elle le cours payant ?

Parce que l'inscription gratuite produit un vrai jeton d'authentification, et que ce jeton ouvre plus que ce que le propriétaire imaginait. La page d'inscription servait à collecter des adresses e-mail, c'est-à-dire un outil marketing. Techniquement, c'est une porte d'entrée vers la base de données.

Le propriétaire pensait que le paywall protégeait son contenu. Il protégeait en réalité l'affichage : le site montrait « ressource introuvable » aux non-abonnés, mais l'API de la base renvoyait le texte complet à tout compte connecté. Un paywall qui vit dans l'interface se contourne en parlant directement à l'API.

C'est la leçon à retenir pour un dirigeant : chaque page qui crée un compte est une page qui distribue un jeton. Demandez-vous ce que ce jeton permet de lire, au-delà de ce que l'écran affiche.

Quelle est la chaîne technique, étape par étape ?

La chaîne tient en trois maillons, et il suffit qu'un seul soit solide pour qu'elle casse.

1. Inscription ouverte avec confirmation automatique. Le service d'authentification acceptait n'importe quelle adresse et validait le compte immédiatement, sans e-mail de vérification ni CAPTCHA.
2. Politique RLS trop large. La règle de sécurité au niveau des lignes (RLS) de la table de contenu vérifiait que le rôle était « authenticated ». Elle ne vérifiait pas que l'utilisateur avait un abonnement actif.
3. Contenu premium dans la même table que le contenu public. Un simple filtre sur la visibilité suffisait à récupérer les articles réservés, texte complet compris.

Un point mérite d'être souligné : corriger seulement l'inscription ne suffit pas. Même avec une confirmation d'e-mail, n'importe qui avec une vraie adresse reste « authentifié ». Le correctif décisif est la politique RLS.

Qu'est-ce qui était bien sécurisé ?

Le socle était sain, ce qui rend le défaut d'autant plus instructif. Les points suivants tenaient :

• Écritures bloquées : les tentatives d'insertion anonymes étaient rejetées par RLS sur les tables testées.
• Données personnelles protégées : profils, abonnements et listes de suivi ne revenaient rien aux visiteurs anonymes, et un compte connecté ne voyait que ses propres lignes.
• Stockage fermé : aucun compartiment de fichiers lisible publiquement.
• Clé publique correctement traitée : la clé « anon » visible dans le code du navigateur est faite pour être publique. Elle ne constitue pas une faille : la frontière de sécurité est la RLS.

L'équipe avait donc fait la partie difficile. Elle a oublié une seule question : « qui a le droit de lire cette ligne ? »

Quels autres constats l'audit a-t-il relevés ?

Les autres constats, classés par gravité, pèsent moins que le contournement mais racontent la même histoire d'hygiène.

Le cas de la table de configuration illustre une règle du métier : quand un test risquerait de modifier des données réelles, on s'arrête et on signale le doute au propriétaire.

Comment corriger ce type de faille ?

La correction est courte, et la priorité va à la politique RLS. Voici l'ordre recommandé.

1. Lier la lecture au statut d'abonnement. La politique RLS doit exiger un abonnement actif pour toute ligne marquée « membres ». Le droit se vérifie dans la base, pas dans l'interface. Voir la documentation Row Level Security de Supabase.
2. Fermer l'inscription automatique. Activer la confirmation d'e-mail, ajouter un CAPTCHA, ou conditionner la création de compte au paiement.
3. Vérifier les droits côté serveur. Pour le contenu de valeur, passer par une fonction serveur qui contrôle l'abonnement à chaque lecture, plutôt que d'exposer la table.
4. Ne pas exposer la table de configuration. Servir les réglages depuis le serveur, ou limiter la lecture aux rôles qui en ont besoin.
5. Contrôler UPDATE et DELETE. Un INSERT bloqué ne dit rien des autres opérations.
6. Durcir le périmètre. Authentification d'e-mail stricte, politique de contenu, clés de test retirées des versions de production.

Ces points relèvent des familles « autorisation défaillante » décrites par l'OWASP, notamment API1 (autorisation au niveau des objets) et API5 (autorisation au niveau des fonctions). Pour approfondir les pièges de la RLS, lisez notre guide sur les erreurs RLS et les cinq erreurs de configuration qui contournent un paywall.

Quel rapport avec les agents IA ?

Un agent ou un chatbot branché sur la même base avec le jeton d'un utilisateur hérite exactement de la même lecture trop large. Si la base répond « oui » à tout compte connecté, l'agent répondra « oui » aussi, et un utilisateur malveillant peut lui demander de résumer, citer ou envoyer ailleurs ce que la politique laisse passer.

C'est le risque central des agents : le modèle n'est pas un contrôle d'accès. Une consigne dans le prompt du type « ne montre le contenu premium qu'aux abonnés » est une règle souple, qu'une injection de prompt peut contourner. Le droit doit être vérifié en dehors du modèle, dans la base ou dans une couche d'autorisation qui décide avant l'appel d'outil.

Pour un agent connecté à vos données, testez au minimum :

• ce qu'un compte gratuit, ou le compte d'un autre client, peut lui faire lire ;
• si les outils de l'agent portent le jeton de l'utilisateur ou une clé de service, plus large ;
• si les droits sont revérifiés à chaque appel, pas seulement à l'ouverture de session.

Ces vérifications correspondent à la surface décrite dans notre page sur la sécurité des agents IA, et c'est le terrain d'un red team d'agent IA. L'article sur l'isolation des données d'un agent multi-tenant détaille le même problème côté agent, et l'étude de cas du webhook n8n montre une autre chaîne où un contrôle manquant a suffi.

Comment CleanIssue peut-il vous aider ?

Si votre produit mélange comptes utilisateurs, contenu payant et un agent IA, la question à poser est simple : un compte gratuit peut-il lire ce qu'il ne devrait pas, directement ou par l'intermédiaire de l'agent ? Le Red Team Agent Express répond à cette question en 5 jours pour 1 900 €, sur un agent précis, avec un rapport écrit et des preuves reproductibles. Il est toujours payant : aucune garantie « rien trouvé, rien payé ».

Le premier contact est un rendez-vous découverte gratuit de 30 minutes, consacré à cadrer le périmètre avant toute proposition.

Les autres études de cas

• Webhook n8n : comptes administrateur ouverts
• Application SaaS de rédaction IA
• Plateforme d’échange de crypto-actifs
• Restaurant : back-office ouvert par un fichier oublié