Un portail client peut etre beau, rapide et bien pense, tout en restant fragile sur l'essentiel. En pratique, quelques oublis suffisent pour exposer des donnees, casser une permission, ou laisser une action sensible trop facile.
Avant une mise en ligne, le plus utile n'est pas un discours abstrait sur la securite. Le plus utile, c'est une verification concrete des points qui cassent le plus souvent.
1. Verifier la frontiere client / serveur
Le premier controle est simple : tout ce qui touche un secret, un role admin ou une action privilegiee doit rester cote serveur.
Cherchez notamment :
- l'usage de
service_role - les variables d'environnement sensibles
- les modules importes dans des composants
"use client"
Si la frontiere est floue, corrigez-la avant le reste.
2. Verifier les roles et les chemins d'acces
Un portail client repose souvent sur plusieurs types d'utilisateurs :
- administrateur
- collaborateur interne
- client final
Il faut verifier que chaque parcours voit exactement ce qu'il doit voir, et rien de plus.
Faites des tests avec de vrais comptes de chaque type. Ne vous basez pas seulement sur votre compte admin.
3. Verifier les GRANT des tables exposees
Si votre portail utilise la Data API Supabase, les tables accessibles doivent avoir des GRANT explicites propres. Depuis les changements 2026 de Supabase, ce point est encore plus important.
Posez-vous cette question table par table :
anonen a-t-il besoin ?authenticateden a-t-il besoin ?service_roleseul suffit-il ?
Un GRANT trop large n'est pas un detail. C'est une surface d'exposition directe.
4. Verifier la RLS et les policies
Une table accessible n'est pas encore une table bien securisee.
Controlez :
- que la RLS est activee
- que les policies couvrent bien les lectures
- qu'elles couvrent bien les ecritures utiles
- qu'elles filtrent avec les bons identifiants
Le bon test est tres concret : un utilisateur A ne doit jamais voir ou modifier les donnees de B sans justification produit claire.
5. Verifier les actions sensibles
Certaines actions meritent une revue a part :
- suppression de compte
- changement de role
- acces admin
- export de donnees
- lecture de factures, messages, documents
Ces actions doivent passer par un controle serveur clair, avec une verification explicite des droits.
6. Verifier les contenus publics
Beaucoup de portails melangent :
- contenu public
- contenu prive
- contenu semi-public de type CMS
Verifiez que les tables publiques ne donnent pas plus que ce qui doit etre visible par un visiteur non connecte.
Ce controle est simple a oublier quand le projet combine site marketing et espace client.
7. Verifier les secrets et l'environnement
Une mise en ligne propre suppose aussi :
- pas de secret prefixe par
NEXTPUBLIC - pas de cle sensible dans le repo
- des variables definies correctement sur l'environnement de production
- aucune confusion entre cles publiques et cles serveur
Ce point semble basique, mais il revient tres souvent.
8. Verifier les en-tetes de securite
Un portail client a interet a sortir avec une base propre sur les headers :
Content-Security-PolicyStrict-Transport-SecurityX-Content-Type-OptionsReferrer-PolicyPermissions-Policy
Le but n'est pas d'empiler des headers sans les comprendre, mais de couvrir les vraies surfaces utiles.
9. Verifier le comportement en cas d'erreur
La securite n'est pas seulement une question d'acces. C'est aussi la maniere dont l'application reagit :
- un utilisateur voit-il un message clair en cas d'acces refuse ?
- une erreur revele-t-elle trop d'informations internes ?
- le front continue-t-il d'afficher des donnees apres une session invalide ?
Un portail sain gere aussi bien les refus que les succes.
10. Verifier avec une checklist de pre-prod
Avant ouverture au public, faites une passe finale :
- test avec compte client
- test avec compte interne
- test avec compte sans droit
- test des actions critiques
- verification des tables exposees
- verification des secrets et headers
Si vous manquez de temps, faites au moins cela. C'est le coeur du risque.
Ce qu'il faut retenir
Un portail client Next.js + Supabase peut etre tres propre si vous verifiez les bons points avant la mise en ligne : frontiere serveur/client, GRANT, RLS, actions sensibles, contenu public, secrets et headers.
Le plus gros danger n'est pas un bug spectaculaire. C'est une somme de petits oublis qui, ensemble, ouvrent une vraie faille. Une checklist simple et disciplinee evite deja beaucoup de problemes.