Authentification et autorisation

L’authentification et l’autorisation sont deux notions distinctes, souvent confondues. Cette confusion peut conduire à mal décrire les défauts et à négliger de vrais risques d’accès.

→L’authentification répond à la question : « Qui êtes-vous ? »
→L’autorisation répond à la question : « Que pouvez-vous faire ? »

Saisir un identifiant et un mot de passe ne donne pas accès à toutes les ressources ni à toutes les actions. Inversement, certaines ressources peuvent être accessibles sans connexion, mais de façon limitée. Testez ces couches séparément.

Authentification

L’authentification confirme l’identité d’un utilisateur, d’un service ou d’un appareil. Le système détermine si le sujet est bien celui qu’il prétend être.

→Identifiant et mot de passe
→Code à usage unique
→MFA
→SSO
→Jeton d’accès ou jeton d’identité
→Certificat
→Identifiants de communication entre machines

L’authentification dépasse la connexion réussie et couvre un cycle de vie :

→Un utilisateur ou un système présente un justificatif d’identité
→Le serveur le valide
→Une session est créée ou un jeton est émis
→Le justificatif possède une durée de validité
→Il peut expirer, être révoqué, être corrompu ou être utilisé dans un contexte inadapté

Les vérifications d’authentification vont donc généralement au-delà des tentatives de connexion valides et invalides.

Autorisation

Une fois le sujet identifié, l’autorisation détermine les actions permises.

→Un utilisateur ordinaire peut consulter uniquement ses propres commandes
→Un responsable peut consulter les commandes de son équipe
→Un administrateur peut modifier les statuts des utilisateurs
→Un service d’intégration peut lire les données sans pouvoir les supprimer
→Un utilisateur anonyme peut ouvrir une page publique, mais pas un espace personnel

L’autorisation évalue les permissions, les rôles, les politiques, la propriété des objets et les restrictions métier, plutôt que l’identité.

Un utilisateur correctement authentifié peut ne pas avoir le droit d’effectuer une action. Il s’agit d’une couche distincte de contrôle d’accès, pas d’une erreur de connexion.

Pourquoi les confond-on ?

Leurs échecs peuvent sembler similaires de l’extérieur.

→L’utilisateur n’est pas connecté
→Son jeton a expiré
→Son jeton est invalide
→Il est connecté mais ne possède pas le rôle requis
→Il possède le rôle, mais tente d’ouvrir la ressource de quelqu’un d’autre
→Le backend vérifie mal les droits d’accès

L’UI peut représenter toutes ces situations par « accès refusé » ou « connexion requise ». Les testeurs QA doivent distinguer les défauts, les causes et les priorités.

Vérifications QA de l’authentification

→Les identifiants valides permettent la connexion
→Les identifiants invalides ne permettent pas la connexion
→Les jetons et sessions expirés sont correctement traités
→La déconnexion fonctionne correctement
→La déconnexion invalide la session selon les exigences
→L’accès ne persiste pas au-delà de la durée prévue
→Les fonctions de mémorisation de connexion, jetons de renouvellement, MFA et SSO fonctionnent correctement
→Les identifiants ne fuient pas dans les URL, le stockage local, les journaux ou les traces réseau
→Les connexions répétées sur plusieurs appareils ou onglets se comportent correctement

Testez le cycle de vie complet des justificatifs, en plus du parcours nominal. De nombreux défauts apparaissent au renouvellement, à l’expiration, à la révocation ou à la réutilisation des jetons et sessions, plutôt qu’à la connexion initiale.

Vérifications QA de l’autorisation

→Les utilisateurs voient uniquement les données autorisées
→Les utilisateurs effectuent uniquement les actions autorisées
→Les droits sont appliqués par le backend autant que par l’UI
→Des ID directs ne permettent pas d’exposer les ressources d’un autre utilisateur
→Les rôles ne possèdent pas de permissions excessives
→Les actions de boutons masqués dans l’UI ne restent pas accessibles via l’API
→Les règles sont cohérentes entre web, mobile et API
→Les changements de rôle, de statut ou d’état d’objet n’accordent pas accidentellement des droits

Vérifier l’autorisation uniquement via l’UI est un piège courant. Un bouton masqué ne prouve pas la protection. Des tests efficaces incluent presque toujours des appels API directs, ou au moins l’inspection des réponses du backend.

Défaillances fréquentes

→Remplacer un ID dans une requête expose les données d’un autre utilisateur
→Le jeton d’un ancien utilisateur fonctionne encore après déconnexion
→Un changement de rôle dans l’administration n’est pas pris en compte rapidement
→Un service vérifie le rôle, mais pas la propriété de l’objet
→Le frontend affiche un refus tandis que le backend exécute la requête
→Un jeton d’accès reste valide plus longtemps que prévu
→Des événements critiques ne révoquent pas les jetons de renouvellement
→Des utilisateurs anonymes reçoivent plus de données qu’autorisé

Ces défauts ont souvent plus d’impact sur la qualité et la sécurité du produit que les problèmes ordinaires d’interface.

Exemple pratique

Prenons un système de commandes.

L’utilisateur A se connecte et ouvre la commande #1001, puis remplace l’ID par #1002 dans une requête réseau ou dans l’URL.

Si le système renvoie la commande d’un autre utilisateur, l’authentification a déjà réussi. C’est l’autorisation qui a échoué, car le backend n’a pas vérifié la propriété.

Cette vérification est essentielle en QA. La connexion et l’émission de jetons peuvent fonctionner parfaitement, tandis qu’un contrôle d’accès insuffisant aux ressources rend le produit vulnérable.

Points essentiels pour les testeurs QA

→L’authentification et l’autorisation sont des couches distinctes.
→L’authentification vérifie l’identité ; l’autorisation vérifie les droits d’accès.
→Une connexion réussie ne permet pas toutes les actions.
→Les restrictions de l’UI doivent être appliquées par le backend pour protéger efficacement.
→L’accès aux données et aux actions d’un autre utilisateur constitue un domaine de test essentiel.
→Testez les cycles de vie des jetons, des sessions et des rôles aussi attentivement que la connexion.

Lectures complémentaires

→Dans cette base de connaissances : HTTP et HTTPS
→Dans cette base de connaissances : JWT, OAuth 2.0 et clés API
→Ressource externe : Aide-mémoire OWASP sur l’autorisation

Matrice des rôles et de la propriété pour un exercice local

Séparez l’identité du droit d’accès à un objet précis. Dans l’environnement pédagogique local, l’enregistrement 1 appartient à l’utilisateur A et le 2 à l’utilisateur B. Un utilisateur peut lire son propre enregistrement ; un administrateur peut lire les deux. Les chaînes demo-user-a, demo-user-b et demo-admin sont des données de test synthétiques, pas de vrais identifiants.

plain text

Identité	Requête	Résultat attendu
Sans jeton	GET /records/1	401 et WWW-Authenticate
Jeton inconnu	GET /records/1	401 et aucune donnée de l’enregistrement
Utilisateur A	GET /records/1	200, propriétaire a
Utilisateur A	GET /records/2	403, aucun champ du propriétaire ni de l’enregistrement
Utilisateur B	GET /records/2	200, propriétaire b
Administrateur	GET /records/2	200, propriétaire b
Utilisateur A	POST /items avec un corps valide	403 et aucun nouvel élément

Pour l’accès interdit à un objet, vérifiez le corps de la réponse et son statut : un code d’erreur accompagné des données d’un autre utilisateur reste un échec. Une réponse 401 concerne les justificatifs d’identité ; 403 indique que l’opération est refusée. Un vrai produit peut utiliser 404 pour dissimuler l’existence d’un objet : choisissez les attentes selon son contrat. Cet exercice utilise délibérément 403.

Cet environnement n’implémente ni connexion, ni vérification JWT, ni expiration, ni révocation, ni stockage de sessions. Testez ces mécanismes séparément dans un environnement autorisé ; le refus d’une chaîne inconnue arbitraire ne prouve pas le fonctionnement de l’expiration des jetons.

Pour aller plus loin

Télécharger le laboratoire local de pratique (ZIP)

Mécanismes des jetons et des identifiants

Écritures négatives et effets de bord

MDN : réponse 401