Chapitre 9.3 — Symfony : firewalls & auth

⏱️ TL;DR — Symfony fournit un composant Security mûr et secure by default — à condition de le comprendre. Le firewall intercepte les requêtes d’une zone (main, admin) et gère l’authentification via des authenticators (form login, JSON login, access token, remember me…). Le security.yaml est le cœur : il déclare les firewalls, le password hasher (auto = argon2id/bcrypt — rappel Partie 3), les providers d’utilisateurs, et l’access control. Les mots de passe passent par UserPasswordHasherInterface (jamais en clair), la session est gérée par le framework (rotation à la connexion incluse). Le piège : désactiver ces protections « pour que ça marche » (route hors firewall, hasher plaintext, security: false).

🎯 Objectifs

• Comprendre le rôle du firewall et sa configuration dans security.yaml.
• Configurer le password hasher (auto) et hacher/vérifier via UserPasswordHasherInterface.
• Comprendre les authenticators (form login, etc.) et le cycle d’authentification.
• Éviter les pièges : routes hors firewall, hasher faible, access_control mal ordonné.

Le firewall : la porte d’entrée

Dans Symfony, la sécurité d’accès est organisée autour des firewalls. Un firewall couvre un ensemble d’URL (défini par un pattern) et décide comment les requêtes de cette zone sont authentifiées. La plupart des applis ont un firewall principal (main) couvrant tout le site, parfois un firewall séparé pour une zone d’API ou d’admin.

# config/packages/security.yaml (structure simplifiee)
security:
  password_hashers:
    Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'
  providers:
    app_users:
      entity: { class: App\Entity\User, property: email }
  firewalls:
    dev:
      pattern: ^/(_(profiler|wdt)|css|images|js)/
      security: false            # ressources de dev, hors securite
    main:
      lazy: true
      provider: app_users
      form_login:
        login_path: app_login
        check_path: app_login
        enable_csrf: true        # protection CSRF du formulaire de login
      logout:
        path: app_logout
      remember_me:
        secret: '%kernel.secret%'
        # ...
  access_control:
    - { path: ^/admin, roles: ROLE_ADMIN }
    - { path: ^/profil, roles: ROLE_USER }

Points de sécurité de cette config :

• password_hashers: 'auto' : Symfony choisit le meilleur algorithme disponible (argon2id/bcrypt) et gère le sel/coût. On ne configure jamais plaintext ou un hachage faible.
• enable_csrf: true sur form_login : protège le formulaire de connexion contre le CSRF.
• access_control : les règles d’accès par URL, évaluées dans l’ordre (la première qui matche gagne — piège fréquent, voir plus bas).

Le password hasher : ne jamais toucher au clair

Le hachage des mots de passe (Partie 3) est géré par le composant. À l’inscription/au changement, on passe le mot de passe en clair au hasher, qui renvoie le hash à stocker ; à la connexion, le firewall vérifie automatiquement.

// A l'inscription : hacher via le service (jamais stocker le clair)
public function register(UserPasswordHasherInterface $hasher, Request $request): Response
{
    $user = new User();
    $user->setEmail($email);
    $user->setPassword($hasher->hashPassword($user, $plainPassword)); // argon2id via 'auto'
    // ... persister
}

Le mot de passe en clair ($plainPassword) ne doit pas être persisté ni loggué. Symfony a d’ailleurs un attribut/#[Ignore] et des conventions pour éviter de sérialiser le clair. La vérification à la connexion est faite par le firewall (comparaison en temps constant incluse) — tu n’écris pas la comparaison toi-même.

⚠️ Piège — Ne configure jamais un hasher plaintext ou un algorithme faible « pour tester » (ça se retrouve en prod), et ne compare jamais les mots de passe à la main. Laisse auto : Symfony gère l’algorithme fort, le sel, le coût, la comparaison en temps constant et le rehash automatique quand le coût évolue. Toute tentative de « faire plus simple » ici casse la sécurité.

Les authenticators : comment on prouve son identité

Symfony (composant Security moderne) gère l’authentification via des authenticators. Les plus courants, activés dans security.yaml :

• form_login : connexion par formulaire (email/mot de passe), avec enable_csrf.
• json_login : connexion par payload JSON (pour une SPA/API sur le même domaine).
• access_token : authentification par jeton (API), via un handler qui valide le token.
• remember_me : cookie « se souvenir de moi » (signé) — à configurer avec soin (durée, secret).
• Authenticator personnalisé : en implémentant l’interface dédiée pour des cas spécifiques (SSO, magic link…).

Le firewall orchestre le tout : il déclenche l’authenticator, gère l’échec (retour au login), le succès (création de la session, régénération de l’id de session — anti-fixation, Partie 4), et expose l’utilisateur courant ($this->getUser(), #[CurrentUser]).

💡 Réflexe — Utilise les authenticators fournis plutôt que de réinventer l’authentification. Ils intègrent déjà les bonnes pratiques (CSRF sur le login, rotation de session, gestion des échecs, protection contre certaines attaques). Pour un besoin spécifique (SSO OIDC — Partie 4, magic link), écris un authenticator personnalisé en t’appuyant sur le composant, plutôt que du code d’auth « à la main » hors framework.

L’access control et son piège d’ordre

access_control protège des URL par rôle/attribut, globalement. Deux points de vigilance :

1. L’ordre compte : Symfony applique la première règle dont le path matche, puis s’arrête. Une règle trop large placée avant une plus spécifique peut « avaler » cette dernière.

# ❌ Mauvais ordre : /admin/... matche la 1re regle (ROLE_USER) et s'arrete
access_control:
  - { path: ^/admin/public, roles: PUBLIC_ACCESS }
  - { path: ^/admin, roles: ROLE_ADMIN }      # jamais atteinte pour /admin/public... et OK pour le reste
# Regle : du plus SPECIFIQUE au plus general.

2. access_control ne suffit pas : il protège des zones d’URL (contrôle grossier), mais pas l’accès par objet (l’IDOR de la Partie 5). Un ROLE_USER autorisé sur /facture peut toujours demander la facture d’un autre si le contrôleur ne vérifie pas l’appartenance. C’est le rôle des voters (chapitre 9.4).

🎯 Côté attaquant — Sur une appli Symfony, l’attaquant cherche : des routes hors firewall (ex. une zone d’API oubliée, security: false mal placé), un access_control mal ordonné laissant passer une zone censée être protégée, un remember_me faible, ou — le plus fréquent — un contrôle par URL présent mais aucun contrôle par objet (IDOR). Il teste les endpoints d’admin sans le rôle, et manipule les ids d’objets. Symfony est solide si la config est stricte ; les failles viennent des contournements et des oublis d’autorisation par objet.

🧭 Sur FormaCampus — Le back Symfony de FormaCampus a un firewall main (site + SPA via json_login sur le même domaine) et un firewall d’API pour les intégrations (access_token). Le hasher est auto (argon2id), le form_login/json_login ont enable_csrf, la session est régénérée à la connexion. L’access_control est ordonné du plus spécifique au plus général et sert de première barrière (zones d’admin en ROLE_ADMIN) — mais l’équipe sait qu’il ne remplace pas l’autorisation par objet, assurée par des voters (chapitre suivant). Aucune route sensible n’est en security: false (réservé aux assets de dev).

✏️ Exercices

Exercice 1 — Répare l’access_control. L’ordre suivant laisse /admin/stats accessible à tout utilisateur connecté alors qu’il devrait être réservé aux admins. Pourquoi, et comment corriger ?

access_control:
  - { path: ^/admin, roles: ROLE_USER }
  - { path: ^/admin/stats, roles: ROLE_ADMIN }

access_control:
  - { path: ^/admin/stats, roles: ROLE_ADMIN }   # specifique d'abord
  - { path: ^/admin, roles: ROLE_ADMIN }         # (ou ROLE_USER selon le besoin) ensuite

Exercice 2 — Le hasher de test. Un dev met password_hashers sur plaintext « juste pour débuguer la connexion en local ». Quels risques, et que faire ?

🧠 Quiz de révision

Chapitre suivant : Voters & contrôle d’accès — l’autorisation par objet de la Partie 5, implémentée proprement en Symfony pour fermer les IDOR.