Autorisation vérifiable en PHP : des permissions sans exceptions

La conception des permissions et de l’autorisation en PHP ne se résout pas avec un écran où l’on attribue des profils. Le problème apparaît lorsqu’une même action dépend de la personne qui l’exécute, de l’organisation pour laquelle elle travaille, de la donnée sur laquelle elle agit et de l’état de cette donnée. Si ces conditions sont réparties entre contrôleurs, requêtes, templates et validations d’interface, le système finit par accumuler des exceptions difficiles à examiner.

L’objectif doit être que chaque décision soit explicite, répétable et vérifiable : une identité tente d’exécuter une opération sur une ressource dans un contexte, et une politique décide si elle est autorisée. Cette approche transforme des règles opérationnelles ambiguës en contrôles techniques que les équipes produit, opérations et développement peuvent examiner conjointement.

Séparer identité, autorisation et périmètre des données

L’authentification répond à la question de savoir qui est l’utilisateur : session, identifiants, fournisseur d’identité ou token. L’autorisation répond à la question de savoir ce que peut faire cette identité. Il ne convient pas de déduire la seconde uniquement à partir de la première ni de les traiter comme une seule couche.

Un rôle regroupe des responsabilités, telles qu’administrateur d’organisation, agent de support ou approbateur. Une permission représente une opération concrète, par exemple invoice.read, invoice.approve ou member.invite. Le périmètre détermine sur quelles ressources cette opération est valable : factures d’une organisation, dossiers d’une unité ou enregistrements propres.

Cette distinction évite une erreur fréquente : accorder la permission de lecture des factures et supposer que cela permet de lire n’importe quelle facture. La politique doit encore vérifier si la ressource appartient à l’organisation active, si l’utilisateur est affecté à l’unité correspondante et si l’état de la ressource autorise l’action demandée.

Construire une matrice d’accès à partir des opérations

Avant de choisir des classes ou des packages, énumérez les ressources et les opérations réelles. Utilisez des verbes métier au lieu d’étiquettes vagues telles que « gérer » : créer une commande, voir une commande, corriger un brouillon, approuver une commande, annuler une commande, exporter des commandes ou modifier des membres.

Pour chaque opération, convenez avec le métier de quatre éléments :

• La ressource et l’action protégée.
• Les profils qui peuvent la demander.
• Le périmètre de données applicable : organisation, unité, propriétaire, portefeuille ou affectation.
• Les conditions de contexte et d’état : organisation active, délégation en vigueur, horaires opérationnels ou document à l’état de brouillon.

La matrice résultante n’est pas le code d’autorisation, mais une spécification révisable. Elle oblige également à détecter les décisions en attente. S’il est indiqué que le support peut « voir les commandes », il faut préciser s’il peut voir les données personnelles, les documents joints, les commandes clôturées ou les informations de toutes les organisations.

Privilégier des actions limitées et stables

Une action trop large concentre les privilèges et rend difficile l’application du moindre privilège. Séparer order.read de order.export, ou user.update de user.assign_role, permet d’accorder l’accès avec précision. Il ne convient pas non plus de créer une permission pour chaque cas particulier : si la différence dépend de la ressource, il s’agit généralement d’une condition de la politique, et non d’un nouveau rôle.

Choisir entre rôles, permissions, attributs et contexte

Les rôles simples fonctionnent lorsqu’il existe peu de profils stables et que les opérations dépendent peu de la donnée. Ils constituent un bon point d’entrée, mais deviennent fragiles si des noms tels que responsable_avec_exportation ou superviseur_unite_nord_uniquement apparaissent. Ces combinaisons encodent des exceptions sous forme de profils permanents.

Les permissions explicites sont adaptées pour découpler les responsabilités des profils et attribuer des capacités de manière administrable. Les attributs servent lorsque la décision dépend de propriétés du sujet, de la ressource ou de l’environnement : organisation, unité, classification, propriétaire, pays ou niveau de risque. Les règles contextuelles complètent le modèle lorsque des conditions transitoires interviennent, comme une délégation active ou la phase d’approbation.

En pratique, un modèle hybride est généralement plus maintenable : les rôles accordent des permissions de base ; une politique évalue les attributs de l’utilisateur et de la ressource ; et le contexte apporte l’organisation sélectionnée ou le canal d’opération. Le rôle ne doit pas remplacer l’analyse de la donnée.

Centraliser les politiques et filtrer les données dès l’origine

Une application PHP a besoin d’un point cohérent pour exprimer les décisions. Il peut se matérialiser par des classes de politique, des services d’autorisation ou des composants équivalents du framework choisi. L’important est que les contrôleurs demandent une décision et que les vues ne soient pas la seule barrière.

if (!$authorizer->can($actor, 'order.approve', $order, $context)) {
    throw new AccessDeniedException();
}

La politique ne doit recevoir que les données nécessaires pour décider : identité, opération, ressource et contexte. Évitez de consulter des variables globales ou de dépendre implicitement de la route actuelle ; cela rend les règles difficiles à tester et à réutiliser.

La vérification individuelle ne suffit pas dans les écrans de liste. Si une requête renvoie des commandes de plusieurs organisations puis que l’interface en masque certaines, une exposition a déjà eu lieu. Appliquez le périmètre dans le repository ou la couche de requêtes : filtrez par organisation autorisée, unité permise ou portefeuille affecté avant de charger les résultats. Pour les ressources par identifiant, vérifiez à la fois l’opération et l’appartenance de la ressource.

Les états et transitions comme partie intégrante de la politique

Les opérations sensibles dépendent souvent de l’état. Un approbateur peut approuver une commande en attente, mais pas une commande annulée ni une commande déjà approuvée. Modélisez explicitement la transition autorisée et validez à nouveau au point qui persiste le changement. L’interface peut désactiver un bouton pour guider, mais la politique du serveur est le contrôle effectif.

Éviter les exceptions permanentes et les refus révélateurs

Les rôles génériques tels qu’« administrateur » nécessitent des limites claires. Un administrateur d’une organisation ne devrait pas devenir automatiquement administrateur de la plateforme. De même, une exception telle que « peut modifier cet enregistrement précis » doit avoir un propriétaire, un motif, une date de révision ou d’expiration, ainsi qu’une traçabilité. Si elle se répète, il manque probablement une règle métier ou un attribut du modèle.

Les refus doivent être utiles sans révéler d’informations sensibles. Pour une requête directe sur une ressource appartenant à autrui, il est généralement préférable d’avoir une réponse impossible à distinguer du fait que la ressource n’existe pas. Lors d’une action sur une ressource déjà visible, il est possible d’indiquer que des permissions manquent sans détailler les règles internes, les affectations ou les attributs protégés.

Consignez les actions sensibles autorisées et refusées lorsqu’elles apportent une valeur opérationnelle : changements de rôles, exportations, approbations, accès délégués et modifications de configuration. L’audit doit inclure l’acteur, l’action, la ressource, l’organisation ou le contexte, le moment et le résultat. Ne consignez ni identifiants, ni tokens, ni données personnelles inutiles.

Tester l’autorisation comme une propriété du produit

Les tests d’autorisation doivent couvrir les décisions autorisées et refusées. Une batterie minimale comprend : un utilisateur disposant d’une permission sur son organisation ; ce même utilisateur face à une autre organisation ; un utilisateur sans permission ; une ressource dans un état non valide ; et un changement de contexte, tel que le retrait d’une affectation ou la fin d’une délégation.

Testez directement les politiques, car elles offrent des diagnostics précis, et ajoutez des tests d’intégration afin de confirmer que les routes, contrôleurs, requêtes et opérations d’écriture appliquent la décision. Les régressions les plus dangereuses sont celles de privilège : l’ajout d’un rôle, d’une route ou d’une optimisation de requête qui étend l’accès involontairement.

• Vérifiez qu’une liste ne contient pas de ressources hors périmètre.
• Vérifiez que connaître l’identifiant d’autrui n’accorde pas l’accès.
• Vérifiez qu’un changement d’état exige la politique correspondante.
• Vérifiez que le retrait d’une permission invalide la capacité à la requête suivante.

Adopter le modèle dans une application aux règles dispersées

Il n’est pas nécessaire de réécrire tout le système. Commencez par inventorier les routes, commandes, tâches planifiées et points d’exportation qui modifient ou exposent des données. Priorisez les actions à fort impact et les ressources partagées entre organisations. Extrayez une politique par domaine, couvrez le comportement actuel avec des tests et corrigez les règles qui accordent plus d’accès que prévu.

Ensuite, remplacez les vérifications dispersées par des appels au service d’autorisation et déplacez le filtrage de périmètre vers les requêtes. Examinez périodiquement les permissions inutilisées, les rôles ayant trop de capacités, les délégations expirées et les exceptions actives. La conception des permissions et de l’autorisation en PHP sera maintenable lorsqu’une nouvelle fonctionnalité pourra répondre, avant son développement, qui opère, sur quelle ressource, sous quelles conditions et avec quelle preuve cela a été vérifié.

Checklist pour chaque nouveau module

• Les opérations métier et leurs ressources sont-elles définies ?
• La matrice distingue-t-elle permission, périmètre et condition d’état ?
• Les politiques sont-elles appliquées en lecture, écriture, exportation et processus non interactifs ?
• Les requêtes filtrent-elles les données avant de les fournir à l’interface ?
• Existe-t-il des tests d’accès autorisé, refusé et entre organisations ?
• Les actions sensibles laissent-elles un audit proportionné et sécurisé ?