Clé privilégiée dans le frontend
Les clés service-role et secret contournent RLS et ne doivent jamais atteindre le navigateur.
Contrôles de sécurité Supabase
Contrôlez la frontière Supabase réellement accessible
Avant la vérification de la propriété du domaine, BoringSec distingue les clés publiques des secrets privilégiés et exécute des sondes limitées en lecture seule. La vérification ne débloque que Injection, XSS, Ports et les moteurs externes Nuclei, OWASP ZAP et Medusa.
À utiliser après toute modification des politiques, du stockage, de l’authentification ou de l’environnement.
Scannez uniquement les systèmes qui vous appartiennent ou pour lesquels vous êtes autorisé. Les moteurs approfondis exigent une autorisation vérifiée et peuvent être indisponibles.
rapport / exemple de constatIllustratif
Critique
Structure d’un exemple de rapport
Une requête anonyme peut lire des lignes
- Preuve
- Une lecture limitée avec le contexte public a renvoyé des données. La preuve est minimisée.
- Ce que cela signifie
- Le chemin observé indique un RLS absent ou trop permissif.
- Corriger et vérifier
- Activez RLS, appliquez le moindre privilège, examinez l’exposition et vérifiez.
Ce constat est illustratif et ne concerne pas votre application. Les rapports réels indiquent le scanner, l’état des preuves et les limites de couverture de la cible.
Scénarios de risque courants
Ce qui mérite une analyse approfondie
Il s’agit de risques pertinents pour les projets Supabase, pas d’affirmations sur chacun d’eux. Un constat apparaît uniquement lorsqu’un scanner fournit une preuve.
Lecture anonyme des lignes
Des politiques absentes ou trop larges peuvent exposer les données via l’API publique.
Stockage public ou énumérable
Les politiques de buckets et d’objets peuvent exposer des fichiers non liés.
Couverture transparente
Ce que chaque surface d’analyse peut prouver
L’URL, le code connecté et les moteurs approfondis autorisés répondent à des questions différentes. BoringSec sépare les sources et affiche les états partiels, bloqués ou indisponibles.
Lire la méthodologie publique (en anglais)Classification du projet et des clés
Dans le rapport initial, détecte les URL prises en charge et différencie clés publiques et formats privilégiés.
Sondes de tables limitées
Avant la vérification de propriété, utilise des lectures plafonnées et indique un état protégé, une exposition vérifiée ou un résultat non concluant.
État du stockage
Contrôle les listes de buckets sans ajouter, modifier ni supprimer d’objets.
Incertitude explicite
Les échecs, limites et rejets réduisent la couverture au lieu de produire une réussite.
De l’observation à la vérification
Un rapport conçu pour l’action suivante
- 01
Observer
Inspectez la réponse publique et lancez les moteurs en arrière-plan applicables.
- 02
Vérifier les preuves
Voyez ce qui a été observé, par quel scanner et avec quel niveau de confiance.
- 03
Corriger en contexte
Utilisez une correction concrète et le contexte pertinent pour RLS Supabase.
- 04
Retester
Lancez une nouvelle évaluation. La surveillance détecte les régressions ultérieures.
Questions avant l’analyse
Une clé anon Supabase est-elle un secret divulgué ?
Non. Les clés publiques sont prévues. RLS et les politiques de stockage constituent la frontière.
L’analyse modifie-t-elle la base ?
Non. Les sondes sont limitées et en lecture seule. Elles n’insèrent, ne modifient ni ne suppriment.
Peut-elle prouver toutes les politiques RLS ?
Non. Elle prouve uniquement les chemins observés. Les rôles authentifiés exigent un contexte autorisé.
Un résultat propre prouve-t-il que Supabase est sûr ?
Non. La couverture partielle, bloquée ou indisponible reste visible.
Contrôlez l’application déployée, puis vérifiez chaque correction
Commencez par l’URL publique. Ajoutez le code ou un contexte authentifié seulement si vous souhaitez étendre la couverture.
Lancer une analyse de sécurité