Le build est presque terminé, puis quelqu’un demande qui devrait voir le dossier. À ce moment, l’application possède déjà son modèle de données, ses comptes et ses intégrations. Ajouter « de la sécurité » revient à coller des règles autour de chemins qui n’ont jamais été conçus pour les respecter.

Je commencerais par les actifs et les frontières. Le navigateur n’est pas fiable, l’API reçoit des données contrôlées par l’utilisateur, le service appelle la base avec une identité et les journaux quittent parfois la machine. À chaque frontière, il faut authentifier la source, autoriser l’action et valider le contenu.

Suivre une demande sensible

Prenons POST /dossiers/471/approuver :

1. TLS protège le transport et permet au client d’identifier le serveur;
2. le middleware valide la session, son expiration et sa signature;
3. l’application vérifie que l’utilisateur possède le rôle et que le dossier appartient à son périmètre;
4. elle relit l’état courant et refuse une approbation déjà annulée;
5. une transaction écrit le nouvel état et l’événement d’audit;
6. la réponse contient un identifiant de résultat, jamais une trace interne.

Cacher le bouton ne constitue aucune autorisation. Un appel HTTP peut être fabriqué. La règle doit vivre côté serveur, près de l’opération. Une requête paramétrée protège l’entrée SQL; l’encodage à la sortie protège le navigateur contre du contenu injecté. Ce sont deux menaces différentes.

Le compte de base n’a besoin que des procédures ou tables utiles. Si l’application est compromise, ce moindre privilège limite l’étendue. Les secrets restent hors du code source, tournent périodiquement et ne s’écrivent jamais dans les logs.

Prévoir la défaillance et l’enquête

Une dépendance d’identité peut tomber. Les opérations sensibles doivent échouer fermées plutôt que d’accepter « temporairement tout le monde ». Le service peut garder les sessions déjà validées pendant une courte durée, mais il doit connaître le risque et l’expiration. Les comptes d’urgence sont rares, surveillés et testés.

L’audit enregistre qui, quoi, quand, objet, décision et corrélation. Il évite les champs libres sensibles et part vers un dépôt où l’administrateur de l’application ne peut pas le réécrire. Une alerte porte sur des comportements : nombreux refus, élévation de rôle, export massif ou accès impossible géographiquement.

Je ferais une modélisation de menace courte avant le premier sprint : diagramme de flux, frontières de confiance, scénarios d’abus et contrôles. Puis les tests automatisés essaieraient l’accès sans session, avec le mauvais rôle, sur l’objet d’un autre client, avec une entrée malformée et après expiration.

Vérifier les dépendances livrées avec le code

L’application hérite aussi du risque de ses librairies. Le build devrait produire une nomenclature avec nom, version et licence, puis comparer les versions aux avis de vulnérabilité. Une alerte indique le chemin réel jusqu’au paquet, pas seulement qu’un nom existe quelque part. Les mises à jour passent les mêmes tests fonctionnels et un délai est défini selon exposition. Une dépendance inutilisée est retirée. Ce mécanisme donne une réponse rapide à « sommes-nous touchés? » et évite le scan de crise dans vingt dépôts après l’annonce d’une faille. Les images de conteneur et outils de build entrent dans le même inventaire.

Le résultat pratique n’est pas un document de sécurité séparé. Chaque histoire fonctionnelle porte ses règles d’accès, ses données sensibles, ses événements d’audit et son comportement en panne. Le build peut alors prouver la frontière au lieu de la découvrir la veille de la mise en ligne.