IC

Iheb Chatti

Ingénierie produit full stack, API scalables, workflows asynchrones et delivery cloud

Publié 19 mars 20263 min readAdvanced

Définir les frontières de validation pour des entrées non fiables

La validation devient complexe quand un même payload peut arriver via API publique, outil admin, import ou replay asynchrone.

SecurityBackendFiabilité

La validation est simple à expliquer et difficile à appliquer de manière cohérente. Les vrais systèmes ne reçoivent pas leurs données par une seule API propre. Ils les reçoivent via formulaires, callbacks partenaires, imports CSV, outils admin et replays workers.

Les problèmes de sécurité commencent souvent lorsqu’un de ces chemins décide silencieusement qu’il est “interne” et donc forcément sûr.

Le problème

Les équipes valident soigneusement les requêtes publiques puis font confiance à des données qui réentrent par des jobs async, des outils internes ou des imports opérationnels. Le payload semble familier, donc le système cesse de le traiter comme non fiable alors que la source et le contexte d’exécution ont changé.

Ce qui casse en pratique

  • Les outils admin contournent des règles que les API publiques imposent systématiquement.
  • Les replays workers traitent des payloads obsolètes ou mal formés parce qu’ils étaient valides sous un schéma plus ancien.
  • Les imports CSV ou documentaires injectent de la donnée médiocre dans des workflows stateful car la validation arrive trop tard.
  • Les règles de nettoyage dérivent entre contrôleurs, serializers et handlers de fond.

Décisions de conception

  • Valider à chaque frontière où une entrée brute devient une intention métier, pas seulement à l’entrée de l’API publique.
  • Distinguer validation structurelle et validation métier afin de séparer payload mal formé et transition invalide.
  • Normaliser les entrées issues d’imports ou callbacks avant qu’elles n’atteignent les services domaine.
  • Garder les validations proches des transitions métier afin que les replays asynchrones ne contournent pas les règles courantes.

Arbitrages

  • Revalider les chemins internes ajoute du coût et de la complexité, surtout pour les replays.
  • Les couches de normalisation ralentissent un peu les outils internes rapides, mais évitent la corruption silencieuse.
  • Des catégories d’erreurs plus explicites améliorent la gestion d’incident, mais demandent plus de discipline de design.

Patterns de production

  • Validateurs spécifiques aux requêtes publiques, imports admin et callbacks partenaires.
  • Versioning de schéma sur les payloads mis en queue pour détecter les formats périmés.
  • Garde métier appliquée autant en synchrone qu’en reprise worker.
  • Catégories de validation structurées et visibles par support et opérateurs.

Ce que je ferais différemment

  • Ajouter plus tôt des validations conscientes de la version pour les replays.
  • Traiter l’outillage admin comme une vraie surface d’attaque et de qualité de donnée.
  • Revoir régulièrement l’ownership des validations, car la dérive apparaît souvent par exceptions opérationnelles.