Audit securite Next.js + Supabase: checklist simple avant production

Avant une mise en production, beaucoup d'equipes pensent "on verra apres". C'est souvent la plus mauvaise fenetre pour decouvrir un probleme de droits, de cle exposee ou de contenu public mal filtre.

Un audit securite n'a pas besoin d'etre lourd pour etre utile. Il doit surtout etre clair, repetable, et concentre sur ce qui casse vraiment un projet Next.js + Supabase.

1. Verifier les cles et secrets

Premier passage obligatoire :

• aucune cle serveur dans le front
• aucune variable sensible prefixee par NEXTPUBLIC
• aucune cle committee dans le repo
• aucun partage informel de secrets dans la doc ou le chat d'equipe

Si cette base n'est pas propre, le reste de l'audit perd deja beaucoup de valeur.

2. Verifier les clients Supabase

Assurez-vous qu'il existe une separation claire entre :

• le client public
• le client serveur

Le point critique est simple : service_role doit rester serveur uniquement.

3. Verifier les tables exposees via la Data API

Listez les tables qui doivent etre atteignables via la Data API et posez-vous, pour chacune :

• quel role y accede ?
• pour quelle action ?
• est-ce vraiment necessaire ?

Depuis 2026, Supabase pousse un modele plus explicite sur les nouvelles tables. Profitez-en pour eviter les expositions larges heritees du passe.

4. Verifier les GRANT

Pour chaque table exposee :

• anon a-t-il seulement ce qu'il doit avoir ?
• authenticated a-t-il seulement les operations utiles ?
• service_role est-il reserve au serveur ?

Cette etape vous force a passer d'une securite implicite a une securite lisible.

5. Verifier la RLS

Une fois les GRANT controles, passez a la RLS :

• la table est-elle bien en row level security ?
• existe-t-il une policy pour chaque action attendue ?
• la policy filtre-t-elle selon la bonne cle metier ?

Si vous n'avez pas de reponse nette a ces questions, il faut relire la table.

6. Verifier les sources d'autorisation

Controlez aussi sur quoi reposent vos decisions d'acces :

• user_metadata est-il utilise la ou il ne devrait pas ?
• app_metadata ou la base metier servent-ils bien de source fiable ?
• le front cache-t-il juste des boutons, ou le serveur et la base controlent-ils vraiment ?

Ce point evite beaucoup de fausses securites.

7. Verifier les routes et actions sensibles

Passez en revue :

• login
• reset mot de passe
• suppression de compte
• changement de role
• acces documents, factures, messages
• operations admin

Chaque action sensible doit avoir une verification explicite. Si vous voyez un "si le bouton est cache alors c'est bon", ce n'est pas bon.

8. Verifier les contenus publics

Un projet hybride a souvent :

• un blog
• un CMS
• un portail prive

Ce melange cree des confusions. Verifiez que les tables publiques ne contiennent pas de brouillons, de config interne ou de donnees privees lisibles par anon.

9. Verifier les headers de securite utiles

Sur la partie web, gardez un socle propre :

• Content-Security-Policy
• Strict-Transport-Security
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

Le but n'est pas de viser la collection parfaite de headers. Le but est de fermer les surfaces principales sans casser le site.

10. Verifier le comportement reel

Un bon audit finit avec des tests concrets :

1. un utilisateur legitime fait le parcours normal
2. un utilisateur sans droit tente le meme acces
3. un visiteur anon tente de lire ce qui ne devrait pas etre public
4. une action admin est testee sans privilege admin

Ce sont ces tests qui revelent les ecarts entre l'intention et la realite.

Une version courte de la checklist

Si vous devez aller vite, gardez au moins cela :

• secrets propres
• separation client serveur
• GRANT explicites
• RLS activee
• policies lisibles
• contenu public limite
• actions sensibles verifiees

C'est le noyau dur.

Ce qu'il faut retenir

Un audit securite Next.js + Supabase utile n'est pas une montagne de theorie. C'est une revue disciplinee des points qui ouvrent vraiment des failles : secrets, clients, GRANT, RLS, contenu public et actions sensibles.

Si vous faites cette passe avant la production, vous evitez une grande partie des erreurs qui coutent ensuite du temps, de la confiance et parfois des donnees.

Sources officielles

• Supabase - Securing your API
• Supabase - Understanding API keys
• Supabase - Row Level Security
• Next.js - Content Security Policy