Une recherche administrative utile ne consiste pas à permettre à n’importe quel utilisateur de consulter n’importe quel champ d’une table. Elle doit faciliter des tâches opérationnelles concrètes tout en respectant les enregistrements que chaque profil est autorisé à voir. Dans une application PHP, cette distinction doit être appliquée côté serveur à chaque route qui renvoie des informations, et pas seulement à l’interface du back-office.
Concevoir une recherche sécurisée dans un back-office PHP nécessite de définir ce que signifie rechercher, quels critères sont autorisés, comment le périmètre d’accès est calculé et quelles limites protègent la base de données. Ces critères s’appliquent aussi bien à une simple requête SQL qu’à un système reposant sur un index de recherche.
Commencez par les tâches et le périmètre d’accès
Avant de choisir les champs ou la technologie, identifiez les tâches que la recherche doit permettre d’accomplir : retrouver une commande à partir de sa référence, trouver un compte par son adresse e-mail ou examiner les incidents selon leur état. Pour chaque tâche, notez qui l’effectue et quels enregistrements cette personne peut consulter. Évitez de définir le périmètre comme « tout ce qui apparaît dans la table » : une personne du support peut, par exemple, avoir besoin d’accéder à certains clients, tandis qu’une personne administratrice peut intervenir sur un autre ensemble.
Traduisez ces règles en un modèle d’autorisation compréhensible : par organisation, équipe, propriétaire, région ou autre relation du domaine. Déterminez également si les droits d’accès peuvent évoluer dans le temps et ce qui se passe lorsqu’un utilisateur perd ses autorisations alors qu’une session est toujours ouverte. L’interface peut masquer certaines options, mais la règle effective doit être vérifiée côté serveur.
Définissez des filtres explicites et validez chaque critère
Concevez une liste limitée de champs interrogeables et de types de filtres. Par exemple, un écran peut accepter une référence exacte, un état sélectionné dans une liste et une période. Ne transformez pas n’importe quel paramètre envoyé par le client en colonne, en condition SQL ou en critère d’accès.
Validez les valeurs côté serveur : vérifiez les formats, les longueurs, les plages, les valeurs autorisées et les combinaisons. Utilisez des requêtes préparées pour séparer les valeurs de l’instruction SQL. Comme les paramètres préparés ne protègent pas à eux seuls les noms de colonnes ou les tris dynamiques, ces éléments doivent provenir d’une liste d’autorisation définie côté serveur.
Les filtres métier et les conditions d’autorisation sont deux choses différentes. Un utilisateur peut demander « état en attente », mais ne doit pas pouvoir envoyer un identifiant d’organisation pour élargir son périmètre. Calculez ce périmètre à partir de l’identité authentifiée et des règles en vigueur, sans faire confiance aux champs modifiables du formulaire.
Appliquez l’autorisation aux lignes, aux décomptes et aux actions associées
La condition d’accès doit faire partie de la requête qui récupère les résultats. Récupérer d’abord les enregistrements puis les filtrer en PHP peut exposer des données dans les logs, la mémoire, les réponses ou des routes auxiliaires ; cela complique également la pagination et le décompte. Dans la mesure du possible, construisez la requête en appliquant conjointement les conditions d’autorisation et les filtres de recherche.
Examinez toutes les sorties associées. Le nombre total de résultats peut révéler combien d’enregistrements existent hors du périmètre autorisé ; les suggestions automatiques peuvent divulguer des noms ou des adresses e-mail ; une exportation peut appliquer des règles différentes de celles de l’écran. Les liens vers les détails et les actions en masse doivent également respecter le périmètre. Évitez les différences de réponse qui permettraient de déduire l’existence d’un enregistrement inaccessible lorsque cette information est elle aussi sensible.
Centralisez la construction des critères d’accès lorsque cela contribue à leur cohérence, mais ne confondez pas une abstraction partagée avec une autorisation automatique : vérifiez que chaque requête et chaque endpoint l’utilisent correctement.
Choisissez entre SQL et un index de recherche
SQL suffit généralement lorsque les filtres sont bien définis, que la pertinence textuelle n’est pas complexe et que la base de données peut traiter la requête avec des index adaptés. C’est une solution directe pour combiner égalités, plages, relations et tris autorisés. Examinez le plan d’exécution et les index avant d’ajouter un autre composant.
Un index de recherche peut être utile si vous avez besoin de tolérance aux fautes, d’analyse linguistique, de pertinence textuelle ou de recherches sur de grands volumes que SQL ne peut traiter avec les objectifs opérationnels requis. Il ajoute toutefois de la synchronisation, des délais de mise à jour, du contrôle d’accès et des opérations supplémentaires. L’index ne remplace pas la base de données comme source de vérité pour les autorisations.
Si l’index contient des données provenant de plusieurs périmètres, vous devez restreindre la requête selon les autorisations avant de renvoyer les documents et prendre en compte la propagation des changements ou des révocations de droits. Pour les actions sensibles, vérifiez à nouveau l’accès auprès de la source de vérité. Définissez le délai acceptable et la conduite à tenir si l’index est obsolète ou indisponible ; une solution de repli peut consister à désactiver temporairement la recherche avancée, et non à omettre les contrôles.
Limitez le coût, le tri et le volume des réponses
Définissez une taille maximale de page et appliquez une pagination stable. Pour les grands ensembles ou les résultats qui changent fréquemment, la pagination par curseur peut éviter certains problèmes liés au décalage des lignes, mais elle exige un ordre cohérent et des critères de continuation clairement définis.
N’autorisez le tri que sur des champs prévus à cet effet et définissez un ordre secondaire déterministe, comme un identifiant unique. Limitez la longueur des recherches textuelles, les périodes et le nombre de filtres ; évitez les recherches vides qui déclenchent des parcours coûteux. Pour les opérations lourdes, envisagez des limites de fréquence et des délais maximaux d’exécution. La recherche ne doit pas renvoyer des champs dont l’écran n’a pas besoin.
Testez les autorisations et les cas limites
Incluez des tests positifs et négatifs pour différents profils et périmètres. Vérifiez que chaque utilisateur retrouve les enregistrements autorisés et n’obtient pas les autres lorsqu’il modifie les filtres, pagine, trie ou demande une page de détail. Ajoutez des cas couvrant les filtres combinés, les valeurs invalides, les résultats vides et les enregistrements dont le propriétaire ou le périmètre a changé.
Testez également les décomptes, les suggestions, les exportations et les actions en masse. Un test utile vérifie non seulement que l’enregistrement d’un tiers n’apparaît pas dans la liste, mais aussi qu’il est impossible de le retrouver à l’aide d’une référence exacte ou d’en déduire l’existence par une réponse auxiliaire. Lorsque les autorisations changent, vérifiez que le comportement est mis à jour conformément à la politique définie.
Les métriques opérationnelles doivent aider au diagnostic sans créer une nouvelle exposition. Enregistrez la latence, les erreurs, le volume des résultats et le type d’opération, en évitant de stocker des termes de recherche sensibles ou des données personnelles inutiles. Limitez l’accès à ces logs et définissez leur durée de conservation. Surveillez séparément les requêtes lentes et les erreurs de l’index afin de distinguer les problèmes de performances des défaillances d’autorisation.
Liste de contrôle avant de publier des modifications
- Les tâches, les profils et les périmètres d’accès sont documentés.
- Les champs interrogeables, les filtres, les tris et les limites sont explicites.
- Le serveur valide les paramètres et n’utilise pas les données du client pour accorder des droits d’accès.
- L’autorisation s’applique aux résultats, aux décomptes, aux suggestions, aux détails et aux exportations.
- SQL ou l’index dispose d’une stratégie de performances et d’une solution de repli en cas de panne.
- Les tests couvrent les accès autorisés et refusés, les changements d’autorisations et les filtres combinés.
- Les logs et les métriques permettent le diagnostic sans conserver inutilement des termes sensibles.
Une recherche administrative est prête lorsqu’elle permet d’accomplir les tâches prévues avec des résultats compréhensibles, des coûts maîtrisés et des limites d’accès vérifiables. Si une amélioration de la pertinence nécessite d’élargir les données interrogeables ou d’introduire un index, évaluez ce changement comme faisant partie du modèle de sécurité et non comme un simple détail d’implémentation.
