Ce que vous recevez concrètement à la fin d'une revue.

Ce que nous avons trouvé

La RLS était activée sur la table transactions, mais ses politiques SELECT et UPDATE vérifiaient seulement que l'utilisateur était connecté, pas que la ligne lui appartenait. L'interface filtrait correctement, ce qui masquait le problème ; un appel direct à l'API REST renvoyait les lignes de tous les clients.

Preuve — requête faite avec le compte de test B (masquée)

curl "https://[projet].supabase.co/rest/v1/transactions?select=*" \
  -H "apikey: [clé anon]" \
  -H "Authorization: Bearer [session du compte B]"

# 200 OK — 1 248 lignes, dont celles du compte A
# et de 37 autres organisations

Impact pour l'activité

Les données financières de tous les clients étaient lisibles, et modifiables, par n'importe quel utilisateur disposant d'un compte, y compris un compte d'essai gratuit.

Recommandation

Restreindre les deux politiques aux lignes de l'organisation de l'utilisateur, et ajouter un test qui échoue si un autre compte peut lire une ligne.

create policy "org members read own transactions"
on transactions for select
using (org_id in (
  select org_id from memberships where user_id = auth.uid()
));

Ce que nous avons trouvé

Le lien d'export de facture passait le jeton de session (JWT) de l'utilisateur en paramètre d'URL. Les URL complètes, jeton compris, étaient conservées dans les logs de l'hébergeur et dans l'historique du navigateur.

Preuve — ligne de log du staging (masquée)

GET /export?invoice=[id]&token=eyJhbGciOi…[masqué] 200

Impact pour l'activité

Toute personne ayant accès aux logs, ou à l'historique d'un ordinateur partagé, pouvait réutiliser une session valide et agir à la place de l'utilisateur jusqu'à l'expiration du jeton.

Recommandation

Transmettre le jeton dans l'en-tête Authorization (ou s'appuyer sur le cookie de session httpOnly), raccourcir la durée de vie des jetons et purger les logs existants qui en contiennent.

Ce que nous avons trouvé

Les contrats signés déposés par les clients étaient stockés dans un bucket public, sous des chemins prévisibles basés sur le numéro de facture.

Preuve — requête sans authentification (masquée)

curl -I "https://[projet].supabase.co/storage/v1/object/public/contracts/INV-2026-0142.pdf"

# HTTP/2 200 — ni session, ni jeton

Impact pour l'activité

Des contrats clients confidentiels étaient accessibles à toute personne qui devinait ou trouvait une URL.

Recommandation

Rendre le bucket privé, servir les fichiers via des URL signées de courte durée vérifiées selon l'organisation de l'utilisateur, et renommer les fichiers existants pour invalider les anciennes URL.

Ce que nous avons trouvé

Les endpoints de connexion et de réinitialisation ont accepté 50 tentatives consécutives depuis la même IP, sans délai ni blocage. Aucun compte n'a été compromis pendant le test.

Observation pendant les tests

50 échecs de connexion en 40 secondes depuis une IP → pas de limite, pas de blocage, pas d'alerte

Impact pour l'activité

Rend réaliste la devinette de mots de passe et l'envoi massif d'e-mails de réinitialisation.

Recommandation

Ajouter une limite par IP et par compte sur les deux endpoints, avec un délai progressif court.

Ce que nous avons trouvé

L'application n'envoie pas d'en-tête Content-Security-Policy. Aucun point d'injection n'a été trouvé pendant la revue.

Observation

En-têtes de réponse : pas de content-security-policy

Impact pour l'activité

Pas une vulnérabilité en soi, mais limiterait les dégâts d'une future injection de script.

Recommandation

Ajouter une CSP, d'abord en mode report-only pour ne rien casser.