Le problème ne commence pas forcément par une attaque. Un back-office conçu pour six personnes accueille soudain trois filiales, un prestataire, le support et cinquante nouvelles actions. Pour aller vite, les rôles s’élargissent, les exports reprennent les filtres de l’écran et un bouton d’administration appelle une route jamais pensée pour plusieurs périmètres.
Le vrai enjeu est de préserver une autorisation compréhensible lorsque les utilisateurs, données et automatisations se multiplient. L’interface n’est qu’un client : chaque requête doit encore prouver qui agit, sur quelle ressource, dans quel état et avec quelle portée. Une permission générique ne suffit plus.
Contre-intuitivement, ajouter un rôle « super manager » peut augmenter la charge plutôt que la réduire. Les exceptions deviennent invisibles, le support hésite à retirer un accès et chaque incident mobilise plus d’experts. Une règle plus précise et un chemin d’élévation temporaire rendent souvent l’exploitation plus rapide.
Dans un back-office métier développé sur mesure, la sécurité doit suivre le workflow réel : filtres, exports, changements d’état, fichiers, intégrations et reprise. Ce guide priorise les contrôles qui ferment une capacité dangereuse sans prétendre qu’une checklist remplace le modèle de menace ou un test adapté.
Comprendre pourquoi la croissance change le risque
Au début, les mêmes personnes connaissent clients, règles et exceptions. L’autorisation implicite se cache dans cette proximité. Quand le produit grandit, de nouveaux rôles utilisent les mêmes routes avec un contexte différent. Une décision « évidente » pour le fondateur devient un privilège global pour un opérateur.
La croissance ajoute aussi des surfaces silencieuses : recherche globale, action en masse, export, API interne, copie de fichier, prévisualisation et accès support. Chacune peut contourner une règle correcte sur la page principale. L’inventaire suit la capacité métier, pas seulement les menus visibles.
Chercher les signaux faibles
Les premiers signaux sont demandes de rôle plus large, actions manuelles en base, comptes partagés, refus difficiles à expliquer, exports non attribués et correctifs différents selon l’écran. Ces frictions montrent que le modèle ne correspond plus à l’organisation avant qu’une fuite soit confirmée.
Cartographier fonctions, données et frontières
La carte associe chaque tâche à ses entrées, ressources, mutations, sorties et effets externes. « Gérer les commandes » est décomposé en consulter, modifier l’adresse, annuler, rembourser, exporter et rejouer une synchronisation. Le risque et la séparation de tâches diffèrent pour chacune.
Les données sont classées par sensibilité et périmètre : tenant, filiale, site, portefeuille ou dossier. La règle indique aussi les états autorisés. Un manager de filiale peut voir un dossier sans pouvoir approuver sa propre modification ou agir après clôture.
Le projet OWASP ASVS fournit des exigences vérifiables couvrant notamment authentification, contrôle d’accès, validation et journalisation. L’équipe l’utilise comme grille de questions, puis adapte profondeur et tests à son architecture et à ses risques.
Renforcer l’authentification sans compte partagé
L’identité personnelle permet révocation, attribution et politiques adaptées. Un compte « admin-agence » partagé rend impossible de savoir qui a téléchargé un fichier et oblige à changer un secret pour tout le groupe. La fédération et l’authentification multifacteur réduisent certains risques, sans corriger une autorisation trop large.
Les sessions sensibles ont une durée, une révocation et une réauthentification proportionnées. Une action irréversible peut demander une confirmation de présence récente, mais répéter le mot de passe sur chaque clic fatigue et favorise les contournements. Le seuil vient du risque et du parcours local.
Séparer secours et usage quotidien
Le compte de secours est dédié, limité, surveillé et exercé. Il ne sert pas à contourner une panne de droits ordinaire. Son ouverture déclenche une alerte et une revue ; sa fermeture invalide sessions et secret selon le mécanisme choisi.
Contrôler chaque action côté serveur
La route reçoit une identité et une ressource ; elle calcule l’autorisation depuis le contexte courant. Cacher un bouton améliore l’expérience mais ne protège pas l’API. Modifier un identifiant dans l’URL, un champ caché ou un appel GraphQL ne doit jamais élargir le périmètre.
Le refus par défaut est appliqué aux nouvelles routes et nouveaux états. La fiche OWASP sur l’autorisation insiste sur moindre privilège, validation à chaque requête et tests. L’équipe couvre aussi les accès horizontaux : voir le dossier voisin reste interdit même avec le bon rôle général.
Les décisions sont centralisées assez pour rester cohérentes, mais conservent le vocabulaire du domaine. Une politique « peutRembourser(command, actor) » explique ressource, tenant, montant, état et séparation de tâches. Elle est testable sans dépendre de la couleur du bouton.
Isoler filiales, tenants et portefeuilles
Le tenant n’est pas un filtre ajouté à la fin. Il appartient aux clés, requêtes, caches, messages, index et exports. Une fonction de recherche qui oublie la contrainte peut traverser les organisations même si la page détail est correcte.
L’application dérive le périmètre depuis l’identité et la ressource autorisée, jamais depuis un paramètre libre accepté tel quel. Les administrateurs multi-entités possèdent une élévation explicite et un contexte visible. Un changement de filiale ferme les onglets, invalide les sélections et recalcule les autorisations.
Tester les caches et traitements différés
Une clé de cache inclut le périmètre pertinent. Un message porte tenant et identité technique autorisée, puis le worker revalide l’état. Une permission accordée lors de la mise en file peut avoir expiré avant l’exécution ; le contrat précise si l’action doit continuer ou être refusée.
Protéger les actions sensibles et leur intention
Suppression, remboursement, changement de droits et export global reçoivent confirmation, motif et contrôle serveur. La protection CSRF s’applique aux requêtes authentifiées par cookie selon l’architecture. Elle empêche certaines soumissions forcées ; elle ne remplace pas l’autorisation ni la validation métier.
La fiche OWASP sur la prévention CSRF décrit plusieurs patrons selon les clients et modes d’authentification. Le projet choisit celui qui correspond réellement à ses cookies, en-têtes et origines, puis le teste sur les routes sensibles.
L’idempotence borne le double clic et le retry. Une confirmation visuelle ne suffit pas si deux requêtes concurrentes créent deux effets. La commande conserve une clé d’opération, un état et un résultat récupérable pour que le support sache si l’action a eu lieu.
Traiter les exports comme une capacité à risque
Un export concentre souvent plus de données que l’écran. Il recalcule les droits sur la requête complète, applique les mêmes périmètres et limite les colonnes. Reprendre un filtre client ou une liste d’identifiants sans vérifier chaque ressource ouvre une fuite horizontale.
La génération asynchrone capture une intention et une politique versionnée. Au téléchargement, l’utilisateur est encore authentifié et autorisé. Le lien est court, non prévisible et n’apparaît pas dans des logs publics. Le fichier possède une durée, un owner et une procédure de suppression.
Rendre le volume explicite
Avant de lancer, l’interface annonce périmètre, nombre estimé et sensibilité. Un seuil local peut exiger approbation au-delà d’un volume observé ou interdire certains champs. Ce seuil protège une conséquence précise ; il n’est pas présenté comme une norme applicable à tous les back-offices.
Sécuriser import, pièce jointe et prévisualisation
Le nom, l’extension et le type déclaré par le navigateur ne suffisent pas. Le serveur limite taille, formats nécessaires, contenu et destination. Le stockage se trouve hors exécution publique, avec un nom généré. L’analyse antivirus est une défense parmi d’autres et son échec produit un état explicite.
La prévisualisation peut interpréter HTML, SVG, PDF ou documents actifs. Elle s’exécute dans une frontière isolée, sans cookies de l’administration et avec des en-têtes adaptés. Télécharger un fichier autorisé ne signifie pas l’ouvrir dans le même contexte que le back-office.
Un import affiche un aperçu, valide schéma et règles, puis exécute par lots idempotents. Les erreurs restent par ligne sans inclure des données sensibles dans un journal général. Le rollback distingue annuler des écritures et compenser des effets déjà envoyés.
Borner intégrations, webhooks et automatisations
Une clé d’API représente une application et un périmètre, pas « tout le back-office ». Elle possède owner, environnement, rotation et dernière utilisation. Les webhooks vérifient authenticité, fraîcheur et rejeu selon le contrat. Les secrets ne sont pas inclus dans l’URL.
Les automatisations internes utilisent les mêmes ports d’autorisation que l’interface ou une politique technique dédiée. Un script SQL avec un accès global ne devient pas sûr parce qu’il tourne dans le réseau de l’entreprise. Chaque action conserve un identifiant et un résultat.
Limiter les effets d’une dépendance compromise
Le client sortant restreint destinations, méthodes et données. Une réponse partenaire n’est jamais injectée telle quelle dans l’interface ou une requête. Les timeouts et retries sont bornés. Le mode dégradé protège la cohérence avant de chercher à terminer toutes les opérations.
Journaliser les décisions sans exposer les données
Le journal d’audit décrit acteur, action, ressource opaque, périmètre, résultat, politique et horodatage. Il n’enregistre ni mot de passe, jeton, document complet ni champ personnel inutile. Les accès à ce journal sont eux-mêmes contrôlés.
L’équipe distingue log de diagnostic et preuve d’action. Le premier peut être échantillonné et changer avec le code ; le second exige intégrité, rétention et gouvernance adaptées. Un événement manquant reste « inconnu », pas « action non réalisée ».
Les alertes portent sur mécanisme : hausse de refus, export anormalement large, usage du secours, changement de rôle et perte de journalisation. Elles conduisent à un runbook. Une hausse n’accuse pas une personne ; elle déclenche une qualification avec contexte.
Encadrer impersonation et accès de support
Le support a besoin de reproduire un problème, pas nécessairement de devenir l’utilisateur. Un mode diagnostic peut afficher tenant, rôle calculé, version et état sans révéler toutes les données. L’impersonation, si elle existe, porte motif, approbation, durée et bannière visible.
Les actions interdites pendant l’impersonation sont bloquées côté serveur : changement de mot de passe, paiement, export complet ou modification de droits selon le produit. L’opérateur et l’identité simulée restent tous deux dans la trace. Aucun audit ne doit attribuer l’action uniquement au client.
Le « bris de glace » couvre les incidents exceptionnels, pas les tickets courants. Il est limité dans le temps et revu après usage. Une procédure trop lourde que tout le monde contourne signale un besoin de diagnostic mieux conçu.
Tester les refus et les scénarios d’abus
Les tests unitaires couvrent politiques de domaine ; les tests d’intégration appellent les routes avec rôles, tenants, objets et états différents. Ils modifient identifiants et champs cachés, rejouent une requête, expirent une session et vérifient l’absence de fuite dans le corps d’erreur.
Un test de sécurité examine recherche, export, fichier, support et action en masse. Le pentest reste utile sur un périmètre réaliste, mais il ne remplace pas la CI ni la correction du modèle. Les constats reçoivent owner, priorité, version corrigée et preuve de non-régression.
Par exemple, si un rôle régional demande un export contenant une ressource d’une autre région, alors la requête entière est refusée ou la ligne exclue selon le contrat explicite. Le test vérifie le fichier final, pas seulement le statut HTTP.
Cas concret : un export traverse une filiale
Cas hypothétique. Un manager sélectionne 240 commandes visibles dans sa filiale et lance un export. Le front envoie les identifiants ; entre-temps, 7 commandes changent d’affectation. Le worker recharge les ressources mais vérifie seulement le rôle « manager », puis inclut les 7 lignes désormais hors périmètre.
La correction remplace la vérification globale par une politique sur chaque ressource au moment du snapshot. Le résultat distingue lignes autorisées, retirées et inconnues. Au-delà d’une divergence locale de 2 %, le pilote suspend le fichier et demande confirmation plutôt que de produire un document ambigu. Ces valeurs illustrent ce cas de recette.
Le téléchargement revalide encore l’identité et la filiale. Le lien expire après la fenêtre décidée localement ; le fichier est supprimé ensuite. La trace conserve nombre et règles, pas les commandes. Le support voit pourquoi 7 lignes manquent sans pouvoir ouvrir leur contenu.
Une équipe non auteure rejoue un changement d’affectation, un retrait de rôle et une perte du worker. Elle reprend la génération avec la même clé d’opération sans dupliquer le fichier. Le cas ferme autorisation, cohérence et reprise, au lieu de corriger seulement le filtre d’écran.
Pour qui et dans quels cas appliquer la méthode
La méthode convient lorsqu’un outil ajoute filiales, rôles, exports, automatisations ou support délégué. Le produit décrit tâches et conséquences ; les développeurs implémentent politiques et tests ; la sécurité challenge menaces et contrôles ; l’exploitation prépare détection et repli.
Les responsables métier valident séparations de tâches et modes dégradés. Le DPO ou le conseil compétent intervient lorsque données personnelles et obligations sont en jeu. Un prestataire reçoit un périmètre et une échéance. Dans une petite équipe, les mêmes personnes peuvent cumuler des rôles, mais la revue d’une action sensible reste indépendante.
Le guide ne constitue ni une certification ni un pentest. Un traitement financier, de santé ou réglementé peut demander des contrôles et validations supplémentaires. L’équipe garde ces exigences dans le même contrat de mise en production.
Erreurs fréquentes d’un back-office en croissance
- Protéger seulement le menu : la route accepte encore une requête directe avec un identifiant voisin.
- Créer un rôle global pour chaque exception : les droits s’accumulent et aucun owner ne sait les retirer.
- Faire confiance au filtre du front : l’export ou l’action de masse reçoit des ressources hors périmètre.
- Journaliser le corps complet : le diagnostic crée une copie sensible plus large que le besoin.
- Partager un compte support : sessions, départs et actions ne sont plus attribuables.
- Corriger sans test négatif : le chemin nominal passe, mais tenant voisin, ancien jeton ou retry restent vulnérables.
Un piège supplémentaire est de multiplier les confirmations visuelles au lieu de réduire les pouvoirs. L’utilisateur clique sans lire et l’API conserve une capacité globale. La priorité reste autorisation, périmètre, idempotence et reprise.
Arbitrer la correction prioritaire
Si une route permet un accès horizontal, alors son contrôle serveur et la réduction du périmètre passent avant l’amélioration du dashboard. En revanche, si le refus existe mais reste inexpliqué, la journalisation de décision et le support peuvent être prioritaires. Dans ce cas, le diagnostic n’élargit jamais la permission.
Si un export global est rarement nécessaire, une élévation temporaire et approuvée peut remplacer un rôle permanent. Plutôt que corriger vingt écrans séparément, l’équipe consolide une politique de domaine et ses tests. Une action irréversible sans idempotence est bloquée jusqu’à ce que son résultat puisse être repris.
Le pilote exige zéro accès inter-tenant sur les scénarios construits, 100 % des actions sensibles attribuées et un repli exercé sur trois parcours. Ces seuils locaux rendent le go réfutable ; ils ne prouvent pas l’absence de toute vulnérabilité.
- D’abord, bloquer les accès hors périmètre et les comptes partagés sur les fonctions critiques.
- Ensuite, tester exports, fichiers et actions de masse avec des données sentinelles.
- Puis, documenter l’élévation, le support et les dépendances techniques.
- Enfin, valider le rollback et élargir seulement les politiques comprises par une autre équipe.
Fermer le contrat de sécurité
Les entrées sont identité, ressource, action, état et périmètre. Les sorties sont autorisation, refus motivé et événement d’audit. Les responsabilités couvrent owner métier, politique technique et support. La journalisation suit la décision ; le monitoring observe refus, secours et pertes de trace.
Les dépendances incluent IdP, stockage, moteur de recherche, worker et fournisseur. Le runbook décrit seuil, rollback, repli et reprise. Les retries sont bornés et les commandes idempotentes. Une file d’échec garde identifiant et motif sans dupliquer le contenu sensible.
Le déploiement active d’abord les politiques en observation sur une cohorte non destructive, compare ancien et nouveau verdict, puis applique les refus. Un drapeau indépendant replie la nouvelle règle sans supprimer la trace. Les migrations de rôles produisent un aperçu et une liste d’écarts avant écriture.
Plan d’action sur six semaines
Semaines 1 et 2 : cartographier les capacités
L’équipe choisit trois tâches sensibles et suit interface, API, worker, export et audit. Elle inventorie rôles, périmètres, comptes et secrets. Dix scénarios négatifs sont écrits depuis des incidents ou hypothèses plausibles, sans inventer de taux de risque.
Semaines 3 et 4 : centraliser les décisions
Les politiques de domaine remplacent les contrôles dispersés. Les tests couvrent rôles, tenants et états. L’export et l’action de masse revalident chaque ressource. Les fichiers passent par stockage isolé et prévisualisation bornée. La trace décrit les refus sans données sensibles.
Semaines 5 et 6 : provoquer puis reprendre
Le pilote expire une session, change une filiale, coupe l’IdP, injecte un fichier interdit et reprend un worker. Une équipe non auteure utilise le secours, puis le ferme. Le métier confirme que les tâches légitimes restent possibles et que les refus sont compréhensibles.
Chaque semaine ferme un artefact : carte de capacité, matrice de politique, jeu négatif, résultat de sentinelles, runbook et compte rendu d’exercice. La revue mesure accès hors périmètre, exceptions, délai de correction et ruptures imprévues sur le contexte local.
À la clôture, le comité tire trois routes et deux exports au hasard. Il retrouve owner, test et trace. Une politique sans scénario négatif, un secours non exercé ou une donnée sentinelle dans les logs bloque l’extension.
- À valider : refus serveur, attribution, isolation et résultat métier pour chaque tâche pilote.
- À bloquer : compte partagé, export sans périmètre ou fichier rendu dans le contexte administrateur.
- À revoir : exceptions, seuils locaux, secrets d’intégration et prochaine campagne de tests.
Relier sécurité, workflow et run
Le diagnostic technique applicatif aide à trouver routes, comptes et flux qui contournent le modèle. Le test des exceptions métier transforme les abus plausibles en scénarios reproductibles.
Le guide d’observabilité des workflows relie refus, cohorte et reprise sans exposer le contenu. Ces pratiques font de la sécurité une propriété du produit et du run, pas une passe isolée avant livraison.
Conclusion : garder le périmètre explicable
Quand un back-office grandit, le danger vient souvent de capacités devenues trop larges : rôle générique, export asynchrone, compte support, fichier ou automatisation. Les protéger exige une décision côté serveur sur identité, ressource, état et périmètre.
La sécurité reste exploitable lorsque les refus sont testés, les actions attribuées et le secours borné. Une politique centralisée ne supprime pas toutes les erreurs ; elle donne un endroit pour les comprendre, les corriger et les rejouer. Les seuils restent locaux et les inconnues visibles.
Dawap peut fermer ces capacités dans une mission de développement web et back-office sur mesure, avec un accompagnement expert du modèle d’autorisation jusqu’aux tests négatifs, au rollback et à la reprise en production.
