Philosophie sécurité
Statut
Document de cadrage sécurité — version initiale.
Vision
La sécurité DMV doit protéger un écosystème territorial multi-applications sans complexifier inutilement l'usage quotidien.
Elle concerne à la fois :
- l'API Laravel centrale ;
- les frontends web et PWA ;
- le backoffice ;
- les modules PlayLoop, AssoSuite et Mairie ;
- les données utilisateurs, acteurs, communes, paiements, contenus, documents, statistiques et futures données IA.
Principes directeurs
- La logique métier sensible doit être contrôlée côté backend.
- L'authentification ne suffit pas : chaque action doit aussi être autorisée.
- Les droits doivent être évalués avec un rôle et un périmètre.
- Les secrets ne doivent jamais être exposés côté frontend.
- Les paiements doivent rester délégués à Stripe pour les données bancaires sensibles.
- L'IA doit être encadrée par une gateway, des quotas, des logs et une validation humaine pour les cas sensibles.
- La conformité RGPD doit être intégrée par conception, sans revendiquer de certification non vérifiée.
État actuel visible
Le repo montre plusieurs briques de sécurité déjà présentes :
- Laravel Sanctum côté API ;
- validation de JWT Supabase via
firebase/php-jwt; - usage historique de Supabase Auth côté frontends ;
- routes API sous
/api/v1; - middleware
identify.appbasé sur le headerX-App-Source; - sources applicatives
dmv,backoffice,playloop,assosuite,mairie; - middleware d'administration ;
- middleware d'accès AssoSuite et Mairie ;
- authentification par token device pour PlayLoop ;
- policies Laravel sur des domaines comme acteurs et publications ;
- configuration Nginx avec HTTPS, headers de sécurité, limites de débit et protection de fichiers sensibles ;
- validation de signature Stripe sur le webhook public.
Vision cible
La cible sécurité est une architecture où :
- Laravel devient le point de contrôle principal des règles sensibles ;
- Supabase/RLS reste documenté comme état historique ou garde-fou selon les usages retenus ;
- les permissions sont centralisées, testables et auditables ;
- les actions sensibles produisent des audit logs exploitables ;
- les appels IA passent exclusivement par une AI Gateway ;
- les accès inter-applications sont limités par scope ;
- la sécurité reste progressive, maintenable et compatible avec la croissance du produit.
Données à protéger
| Domaine | Exemples |
|---|---|
| Identité | comptes, profils, rôles, sessions, tokens. |
| Acteurs | rattachements, revendications, documents, droits de publication. |
| Communes | informations mairie, alertes, contenus institutionnels. |
| Paiements | abonnements, boosts, webhooks Stripe, identifiants de comptes Stripe. |
| Communication | publications, messages, notifications, signalements. |
| Analytics | événements, statistiques, usages, agrégats. |
| IA | prompts, contextes, résultats, coûts, crédits, logs. |
Checklist de référence
- Authentifier l'utilisateur ou le device.
- Identifier l'application source quand la route l'exige.
- Valider les entrées via des règles backend.
- Vérifier le rôle et le périmètre d'action.
- Limiter le débit des routes sensibles.
- Journaliser les actions administratives et sensibles.
- Ne pas exposer de secret, token interne ou donnée bancaire sensible.
- Prévoir export, suppression et rétention des données personnelles.
Risques et points à clarifier
- Source canonique finale entre Supabase Auth/RLS et Laravel.
- Modèle complet des rôles, permissions et scopes.
- Politique de rotation des secrets.
- Durée de conservation des logs techniques et audit logs.
- Niveau de protection Cloudflare réellement activé en production.
- Processus RGPD opérationnel pour export, suppression et consentement.