Aller au contenu principal

Sécurité API

Statut​

Document de cadrage sécurité — version initiale.

Objectif​

L'API DMV doit être le point d'entrée contrôlé de la logique métier commune.

Elle doit protéger les routes, les données, les actions sensibles et les intégrations externes, tout en restant exploitable par plusieurs applications : DMV, backoffice, PlayLoop, AssoSuite, Mairie et futures apps connectées.

État actuel visible​

Le repo montre :

  • routes API sous /api/v1 ;
  • application Laravel configurée en API stateless ;
  • réponses d'erreur JSON ;
  • middleware auth:sanctum ;
  • middleware identify.app ;
  • middleware ensure.admin, device.token, asso.access, mairie.access ;
  • validation de requêtes via Form Requests dans certains modules ;
  • webhook Stripe public avec validation de signature ;
  • configuration Nginx dédiée à l'API.

Protection Nginx visible​

La configuration de déploiement indique :

  • redirection HTTP vers HTTPS ;
  • headers de sécurité ;
  • server_tokens off ;
  • blocage de fichiers sensibles comme .env et .git ;
  • client_max_body_size 20M ;
  • rate limiting global ;
  • rate limiting plus strict sur auth et webhooks ;
  • CORS configuré pour des origines applicatives identifiées.

Ces éléments sont visibles dans le repo. Leur activation exacte en production doit être confirmée par l'infrastructure déployée.

Principes API​

  • Toute route sensible doit être authentifiée.
  • Toute action métier doit être autorisée.
  • Toute entrée utilisateur doit être validée côté backend.
  • Les webhooks publics doivent être protégés par signature.
  • Les erreurs ne doivent pas exposer secrets, stack traces ou détails internes.
  • Les endpoints doivent éviter les retours de données excessives.
  • Les limites de débit doivent protéger auth, recherche, IA, paiement et routes coûteuses.

Header X-App-Source​

Le middleware identify.app exige une source applicative valide parmi :

  • dmv
  • backoffice
  • playloop
  • assosuite
  • mairie

Ce header permet de contextualiser l'appel. Il ne remplace pas un token, un rôle ou une permission.

Sécurité des webhooks​

Le webhook Stripe visible suit une approche correcte :

  • endpoint public ;
  • validation immédiate de la signature ;
  • dispatch asynchrone ;
  • revalidation dans le job ;
  • secret webhook stocké en variable d'environnement.

Cette règle doit servir de modèle pour tout futur webhook externe.

Vision cible​

  • Formaliser une convention de sécurité par type de route.
  • Documenter les routes publiques, authentifiées, admin, device et webhook.
  • Ajouter des tests sur les accès refusés critiques.
  • Étendre le rate limiting aux usages IA, recherche et actions sensibles.
  • Associer les routes sensibles à des audit logs.
  • Versionner l'API sans casser les contrats de sécurité.

Points à clarifier​

  • Liste exhaustive des routes publiques.
  • Politique CORS finale par environnement.
  • Niveau de rate limiting applicatif en plus de Nginx.
  • Stratégie anti-abus pour recherche, IA, notifications et boosts.
  • Format standard des erreurs de sécurité.