Sécurité
Règles minimales de protection pour les comptes, données, secrets, permissions, documents publics et réponses aux incidents.
Accès & moindre privilège
Chaque personne ne doit disposer que des permissions nécessaires à son rôle. Les comptes sont individuels ; ne jamais partager une session ou un identifiant.
Secrets
Les mots de passe, clés API, tokens, identifiants techniques et secrets de signature ne doivent jamais apparaître dans GitHub, Squared Docs, captures publiques ou messages non sécurisés.
Considérer immédiatement le secret comme compromis : le révoquer / régénérer avant de simplement supprimer sa trace.
Données
Limiter la collecte au nécessaire, protéger les données clients et collaborateurs, contrôler les exports et éviter d’utiliser des données réelles dans des captures ou exemples publics.
Documentation publique
Le Squared Help Center étant publié via GitHub Pages, considérer tout contenu mis en ligne comme public. Ne jamais documenter :
- mots de passe ou tokens ;
- données personnelles ou client non destinées au public ;
- clés, endpoints privés ou informations d’infrastructure sensibles ;
- procédures permettant de contourner les contrôles d’accès.
Une documentation utile explique comment travailler correctement sans révéler ce qui rendrait le système plus facile à attaquer.
Incident de sécurité
- Contenir l’exposition.
- Révoquer les accès ou secrets concernés.
- Conserver les éléments nécessaires au diagnostic.
- Évaluer l’impact.
- Corriger la cause.
- Mettre à jour les règles et la documentation.
Supabase & frontend public
Le frontend peut contenir une clé publishable prévue pour le navigateur. Cette clé n’accorde pas de privilège administratif : la sécurité repose sur les politiques RLS et les fonctions autorisées.
- Les clés service-role restent exclusivement côté serveur / Edge Functions.
- Les tables exposées au navigateur doivent avoir RLS activé.
- Les Storage buckets privés utilisent des politiques et des URL signées.
- Une fonction publique ne doit jamais accepter une URL arbitraire ou une opération privilégiée sans contrôle.
Une clé service-role contourne les politiques RLS. Elle ne doit jamais être copiée dans GitHub public, un fichier HTML ou un script exécuté côté navigateur.
Sauvegardes & restauration
Une sauvegarde n’a de valeur que si elle peut être restaurée. Les changements structurels doivent conserver une stratégie de retour et des versions identifiables.