Authentification, autorisation et voters

Comprendre le mécanisme

L’authentification établit un contexte d’identité ; l’autorisation décide ce qui est permis. Un firewall définit un périmètre et ses mécanismes. Un provider retrouve les utilisateurs ; un authenticator construit un parcours d’authentification avec les éléments de validation nécessaires. Les rôles et règles access_control sont utiles pour des politiques générales, tandis qu’un voter exprime une décision sur un attribut et un sujet métier.

Raisonner et vérifier

L’ordre des règles de contrôle peut modifier la règle appliquée : testez les URL publiques et protégées. Ne déduisez pas la propriété d’une ressource depuis un identifiant fourni par le client. Une interface masquant un bouton n’est pas une protection serveur. Les mots de passe sont hachés via PasswordHasher et les refus doivent être vérifiés dans les tests fonctionnels.

Identité et droit

L’authentification établit une identité selon un mécanisme. L’autorisation demeure une décision distincte. Un compte authentifié peut lire ses factures sans pouvoir lire celles du voisin. Séparez le mécanisme de connexion du contrôle de propriété et vérifiez les deux décisions dans les tests HTTP.

Autoriser un sujet

Un voter peut exprimer un droit sur un sujet. Le code doit appliquer les conditions correctes. Un voter reçoit une opération, par exemple EDIT, et un document. Il compare propriétaire, tenant et état métier avec les droits de l’acteur ; denyAccessUnlessGranted doit intervenir avant toute modification.

Premier access_control applicable

Les règles access_control suivent un ordre pertinent. La sélection configurée doit être comprise et testée. Placez une exception publique étroite avant une règle générale protégée lorsque le contrat le demande. Testez les chemins réellement résolus ; une règle générale placée trop tôt peut masquer toutes les suivantes.

Coût du hachage

Les mots de passe demandent un hasher adapté. Le coût des essais hors ligne doit être pris en compte. Utilisez le password hasher du framework et sa vérification, plutôt qu’une comparaison de condensats maison. Prévoyez migration progressive et budget CPU pour les connexions simultanées, sans journaliser les mots de passe.

Frontières des firewalls

Les firewalls ont des contextes et configurations. Le partage dépend des options et du modèle choisi. Une API stateless et une interface avec session peuvent avoir des mécanismes distincts. Vérifiez quel firewall correspond au chemin et comment son contexte traite la déconnexion et le rechargement de l’utilisateur.

Session et intention

Le CSRF complète la sécurité de session. Le navigateur peut envoyer automatiquement son identité. Un formulaire qui change un IBAN doit vérifier son jeton CSRF même lorsque la session identifie correctement le compte. Le navigateur peut envoyer le cookie lors d’une demande provoquée ailleurs.

Retirer un accès

Une désactivation doit être prise en compte selon le cycle choisi. Le modèle doit définir et appliquer le retrait d’accès. Définissez le délai de prise en compte d’un compte suspendu. Une session persistante et un jeton autonome n’offrent pas spontanément le même délai ; testez une demande après suspension avec des credentials déjà émis.

Contrôler avant agir

Le refus doit précéder les mutations sensibles. Le contrôle tardif peut laisser un effet interdit. Un repository save suivi d’un refus laisse potentiellement une écriture durable. Vérifiez dans le test que la demande interdite ne modifie aucune ligne et n’envoie aucun message ou appel externe.

Tester l’isolation

Une règle d’objet doit être testée avec deux acteurs. Le cas tiers vérifie une frontière supplémentaire. Créez Alice, Bob et un document appartenant à Alice. Bob doit échouer même avec un identifiant valide, tandis qu’Alice réussit : ce cas évite de confondre objet absent et objet interdit.

Diagnostics protégés

Les credentials doivent rester hors des logs ordinaires. Les outils de diagnostic demandent un accès protégé. Le profiler et les traces peuvent contenir des cookies ou en-têtes sensibles. Contrôlez leur exposition en production et remplacez les valeurs secrètes par des événements de sécurité minimisés et corrélables.

Atelier guidé : lire, expliquer et vérifier le code

// Extrait de contrôleur ; document trouvé par identifiant :
$document = $repository->find($id);
return $this->render('document.html.twig', ['document' => $document]);

L’extrait charge un document puis le rend immédiatement. Le repository démontre seulement son existence. Introduisez une décision d’autorisation sur ce document pour l’acteur courant, puis testez avec un propriétaire et un tiers. Vérifiez aussi que la réponse d’erreur ne contient ni titre confidentiel ni contenu partiel du document.

L’existence de l’objet et la connexion ne suffisent pas à donner l’accès. La présentation ne décide pas du droit. Un encodage n’établit pas la propriété. Le nom de l’API ne vérifie pas les permissions.

Travail pratique : Écrivez la matrice d’autorisation propriétaire, autre membre et administrateur pour lire et annuler.

Critères de correction : Définissez attributs et sujet, implémentez le voter puis testez tous les couples acteur/action. Vérifiez qu’un refus n’appelle pas le service de mutation.