La sécurité dans une application Symfony

1. Les challenges de la sécurité des applications web

Lors du développement d’un site web, au fur et à mesure de l’ajout de certaines fonctionnalités, comme un espace « membres » ou une zone d’administration, la question de la sécurité devient rapidement une préoccupation importante.

Symfony décompose en deux étapes le processus par lequel l’accès à une ressource est restreint à un nombre limité d’utilisateurs : l’authentification et l’autorisation.

La première étape, l’authentification, consiste à identifier un utilisateur. Une fois l’utilisateur identifié, l’application est chargée de vérifier si ce dernier est autorisé à accéder à la ressource, ou à effectuer l’action demandée.

Au niveau du protocole HTTP, ces deux concepts sont notamment illustrés par les statuts 401 et 403. Le statut 401 signifie qu’une authentification est nécessaire pour accéder à la ressource. Le statut 403, quant à lui, indique que le serveur a correctement identifié l’utilisateur, mais que ce dernier n’est pas autorisé à accéder à la ressource.

2. La sécurité dans Symfony...

1. Pare-feu

Le rôle du pare-feu est de définir les zones de l’application sujettes au système de sécurité.

Lorsque la requête d’un utilisateur correspond aux règles définies par un pare-feu, la sécurité est activée. La requête doit donc passer au travers de ce pare-feu et satisfaire les contraintes d’autorisations qui y sont spécifiées.

Une requête est associée à un pare-feu en fonction de son chemin (path). Reprenons la section firewalls de notre configuration de base :

# config/packages/security.yaml  
  
security:  
  
 # ...  
  
 firewalls:  
   mon_pare_feu:  
     pattern:    ^/  

Ici, nous définissons un pare-feu nommé mon_pare_feu. La directive pattern contient l’expression régulière à appliquer sur le chemin de la requête pour déterminer si elle doit passer par le pare-feu ou non. Comme tous les chemins commencent obligatoirement par un slash, l’expression régulière ci-dessus fait que toutes les requêtes passeront par le pare-feu mon_pare_feu.

Pare-feu pour un sous-domaine

En plus du path, le pare-feu peut analyser le nom de domaine de la requête. Cela se fait avec la directive host :

host:  
 pattern:    ^/  
 host:       ma-section\.example\.com  
 http_basic: ~ 

Pare-feu pour ressources statiques/développement

Certains chemins doivent toujours être accessibles. C’est notamment le cas des ressources statiques (images, feuilles de style, etc.) ou des URL utilisées en interne par Symfony (comme la barre de débogage du Profiler).

Pour éviter de sécuriser malencontreusement ce type de ressources, nous vous conseillons de créer un pare-feu sans règle de sécurité pour ces dernières :

security:  
  
 # ...  
  
 firewalls:  
   dev:   
     pattern:...

1. L’utilisateur

Avec Symfony, l’objet représentant un utilisateur implémente obligatoirement l’interface Symfony\Component\Security\Core\User\UserInterface. Elle garantit les méthodes suivantes :

Si l’authentification des utilisateurs s’appuie sur un nom d’utilisateur associé à un mot de passe, alors l’objet représentant l’utilisateur doit également implémenter l’interface Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface. Elle garantit la méthode getPassword() qui doit retourner le mot de passe de l’utilisateur authentifié.

Récupérer l’utilisateur courant

Pour récupérer l’utilisateur actuellement authentifié, vous disposez du raccourci getUser() dans vos contrôleurs :

<?php 
namespace App\Controller;  
  
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\Routing\Annotation\Route; 
  
class DefaultController extends AbstractController  
{  
   #[Route('/')] 
   public function index()  
   {  
       $utilisateur = $this->getUser();  ...

1. Les rôles, au cœur du processus

Le principe de l’autorisation est simple : vos utilisateurs possèdent des rôles et l’accès à certaines ressources peut être limité à certains rôles. Les rôles sont donc l’élément central du processus d’autorisation. Avant de continuer, il est nécessaire de vous présenter de nouveaux rôles.

Si un utilisateur est derrière l’un des pare-feu que vous avez défini (dans config/packages/security.yaml), il possède obligatoirement au moins un des rôles suivants :

2. Vérifier le rôle de l’utilisateur

Pour sécuriser l’une de vos actions, vous ne devez jamais vous baser sur les rôles retournés par l’objet utilisateur. Les rôles que nous venons de présenter (IS_AUTHENTICATED_*) ne sont par exemple pas présents au niveau de l’objet utilisateur car Symfony utilise en interne un jeton (ou token) pour vérifier une autorisation.

Voici comment vérifier qu’un rôle donné a été accordé à l’utilisateur courant :

<?php 
namespace App\Controller;  
 
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\HttpFoundation\Request; 
use Symfony\Component\HttpFoundation\Response; ...