Aller au contenu principal

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.app basé sur le header X-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

DomaineExemples
Identitécomptes, profils, rôles, sessions, tokens.
Acteursrattachements, revendications, documents, droits de publication.
Communesinformations mairie, alertes, contenus institutionnels.
Paiementsabonnements, boosts, webhooks Stripe, identifiants de comptes Stripe.
Communicationpublications, messages, notifications, signalements.
Analyticsévénements, statistiques, usages, agrégats.
IAprompts, 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.