La sicurezza delle REST API Symfony richiede una combinazione di autenticazione, autorizzazione e corretta gestione dei token. Il LexikJWTAuthenticationBundle versione 3.2, compatibile con Symfony 7.2 e PHP 8.3, fornisce una base robusta per l'autenticazione JWT nelle API di produzione.

Flusso di Autenticazione JWT

Un client invia le credenziali a /api/login_check. Il server le valida, genera un JWT firmato con una chiave privata e lo restituisce. Le richieste successive includono questo token nell'header Authorization per l'autenticazione stateless.

Installazione di LexikJWTAuthenticationBundle in Symfony 7.2

Il bundle si integra con il componente Security di Symfony e gestisce la generazione, validazione e caricamento degli utenti dal payload del token.

bash

# Installare il bundle
composer require lexik/jwt-authentication-bundle

# Generare le chiavi RSA per la firma dei token
php bin/console lexik:jwt:generate-keypair

Il comando keypair crea config/jwt/private.pem e config/jwt/public.pem. Queste chiavi firmano e verificano i token. La passphrase viene memorizzata nella variabile d'ambiente JWT_PASSPHRASE.

yaml

# config/packages/lexik_jwt_authentication.yaml
lexik_jwt_authentication:
    secret_key: '%env(resolve:JWT_SECRET_KEY)%'
    public_key: '%env(resolve:JWT_PUBLIC_KEY)%'
    pass_phrase: '%env(JWT_PASSPHRASE)%'
    token_ttl: 3600  # 1 ora

L'impostazione token_ttl controlla la durata del token. Token di breve durata riducono la finestra di esposizione in caso di furto.

Configurazione dei Firewall Security per l'Autenticazione API

Il componente Security di Symfony richiede la configurazione del firewall per proteggere le route API. L'authenticator json_login gestisce la validazione delle credenziali, mentre jwt protegge le richieste successive.

yaml

# config/packages/security.yaml
security:
    enable_authenticator_manager: true
    
    providers:
        app_user_provider:
            entity:
                class: App\Entity\User
                property: email
    
    firewalls:
        login:
            pattern: ^/api/login
            stateless: true
            json_login:
                check_path: /api/login_check
                success_handler: lexik_jwt_authentication.handler.authentication_success
                failure_handler: lexik_jwt_authentication.handler.authentication_failure
        
        api:
            pattern: ^/api
            stateless: true
            jwt: ~
    
    access_control:
        - { path: ^/api/login, roles: PUBLIC_ACCESS }
        - { path: ^/api/docs, roles: PUBLIC_ACCESS }
        - { path: ^/api, roles: IS_AUTHENTICATED_FULLY }

L'impostazione stateless: true impedisce la creazione di sessioni. Ogni richiesta si autentica indipendentemente tramite il JWT nell'header Authorization.

Creazione di un'Entity User con Hashing della Password

L'entity User implementa UserInterface e PasswordAuthenticatedUserInterface. Symfony 7.2 utilizza queste interfacce per l'integrazione con il sistema di sicurezza.

src/Entity/User.phpphp

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;
use Symfony\Component\Security\Core\User\UserInterface;

#[ORM\Entity]
#[ORM\Table(name: 'users')]
class User implements UserInterface, PasswordAuthenticatedUserInterface
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 180, unique: true)]
    private ?string $email = null;

    #[ORM\Column]
    private array $roles = [];

    #[ORM\Column]
    private ?string $password = null;

    public function getUserIdentifier(): string
    {
        return (string) $this->email;
    }

    public function getRoles(): array
    {
        $roles = $this->roles;
        $roles[] = 'ROLE_USER';  // Ogni utente ha ROLE_USER
        return array_unique($roles);
    }

    public function getPassword(): ?string
    {
        return $this->password;
    }

    public function eraseCredentials(): void
    {
        // Cancella dati sensibili temporanei se memorizzati
    }
}

L'hashing della password utilizza la configurazione password_hashers di Symfony. L'algoritmo auto seleziona l'hasher più forte disponibile.

Implementazione dei Refresh Token per Sessioni Prolungate

I token JWT scadono. Senza refresh token, gli utenti devono ri-autenticarsi frequentemente. Il JWTRefreshTokenBundle estende l'autenticazione con refresh token di lunga durata memorizzati nel database.

bash

# Installare il bundle refresh token
composer require gesdinet/jwt-refresh-token-bundle

yaml

# config/packages/gesdinet_jwt_refresh_token.yaml
gesdinet_jwt_refresh_token:
    refresh_token_lifetime: 2592000  # 30 giorni
    user_identity_field: email
    ttl_update: true  # Estende il TTL ad ogni utilizzo

L'endpoint refresh scambia un refresh token valido per un nuovo access token senza richiedere le credenziali.

yaml

# config/routes.yaml
api_refresh_token:
    path: /api/token/refresh
    controller: gesdinet.jwtrefreshtoken::refresh

Lato client, il refresh token dovrebbe essere memorizzato in modo sicuro. I cookie HTTP-only offrono maggiore protezione rispetto a localStorage contro attacchi XSS.

src/EventListener/JWTCreatedListener.phpphp

namespace App\EventListener;

use Lexik\Bundle\JWTAuthenticationBundle\Event\JWTCreatedEvent;
use Symfony\Component\HttpFoundation\RequestStack;

class JWTCreatedListener
{
    public function __construct(private RequestStack $requestStack) {}

    public function onJWTCreated(JWTCreatedEvent $event): void
    {
        $payload = $event->getData();
        $payload['ip'] = $this->requestStack->getCurrentRequest()?->getClientIp();
        $payload['user_agent'] = substr(
            $this->requestStack->getCurrentRequest()?->headers->get('User-Agent') ?? '',
            0,
            100
        );
        
        $event->setData($payload);
    }
}

Controllo degli Accessi Basato sui Ruoli con Attributi

Symfony 7.2 utilizza attributi PHP per i controlli di sicurezza direttamente nei controller. L'attributo #[IsGranted] sostituisce le annotazioni Security.

src/Controller/AdminController.phpphp

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Security\Http\Attribute\IsGranted;

#[Route('/api/admin')]
class AdminController extends AbstractController
{
    #[Route('/users', methods: ['GET'])]
    #[IsGranted('ROLE_ADMIN', message: 'Accesso amministratore richiesto.')]
    public function listUsers(): JsonResponse
    {
        // Solo ROLE_ADMIN può accedere a questo endpoint
        return $this->json(['users' => []]);
    }

    #[Route('/users/{id}', methods: ['DELETE'])]
    #[IsGranted('ROLE_SUPER_ADMIN')]
    public function deleteUser(int $id): JsonResponse
    {
        // Operazioni critiche richiedono privilegi superiori
        return $this->json(['deleted' => $id]);
    }
}

Per logiche di autorizzazione complesse, i Voter offrono una soluzione flessibile. I Voter decidono se un utente può eseguire una determinata azione su un oggetto specifico.

src/Security/Voter/PostVoter.phpphp

namespace App\Security\Voter;

use App\Entity\Post;
use App\Entity\User;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;

class PostVoter extends Voter
{
    public const EDIT = 'EDIT';
    public const DELETE = 'DELETE';

    protected function supports(string $attribute, mixed $subject): bool
    {
        return in_array($attribute, [self::EDIT, self::DELETE])
            && $subject instanceof Post;
    }

    protected function voteOnAttribute(string $attribute, mixed $subject, TokenInterface $token): bool
    {
        $user = $token->getUser();
        if (!$user instanceof User) {
            return false;
        }

        /** @var Post $post */
        $post = $subject;

        return match($attribute) {
            self::EDIT => $this->canEdit($post, $user),
            self::DELETE => $this->canDelete($post, $user),
            default => false,
        };
    }

    private function canEdit(Post $post, User $user): bool
    {
        // L'autore o l'admin può modificare
        return $post->getAuthor() === $user 
            || in_array('ROLE_ADMIN', $user->getRoles());
    }

    private function canDelete(Post $post, User $user): bool
    {
        // Solo l'admin può eliminare
        return in_array('ROLE_ADMIN', $user->getRoles());
    }
}

Rate Limiting per la Protezione da Attacchi Brute Force

Il componente RateLimiter di Symfony protegge gli endpoint di autenticazione dagli attacchi brute force. La configurazione avviene in config/packages/rate_limiter.yaml.

yaml

# config/packages/rate_limiter.yaml
framework:
    rate_limiter:
        login_limiter:
            policy: 'sliding_window'
            limit: 5
            interval: '1 minute'
        api_limiter:
            policy: 'token_bucket'
            limit: 100
            rate: { interval: '1 minute', amount: 50 }

Il limiter viene applicato in un Event Subscriber per tracciare i tentativi di login falliti.

src/EventSubscriber/LoginThrottlingSubscriber.phpphp

namespace App\EventSubscriber;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\Event\RequestEvent;
use Symfony\Component\HttpKernel\Exception\TooManyRequestsHttpException;
use Symfony\Component\RateLimiter\RateLimiterFactory;

class LoginThrottlingSubscriber implements EventSubscriberInterface
{
    public function __construct(private RateLimiterFactory $loginLimiter) {}

    public static function getSubscribedEvents(): array
    {
        return [RequestEvent::class => 'onKernelRequest'];
    }

    public function onKernelRequest(RequestEvent $event): void
    {
        $request = $event->getRequest();
        
        if ($request->getPathInfo() !== '/api/login_check') {
            return;
        }

        $limiter = $this->loginLimiter->create($request->getClientIp());
        
        if (!$limiter->consume()->isAccepted()) {
            throw new TooManyRequestsHttpException(
                60,
                'Troppi tentativi di login. Riprovare tra un minuto.'
            );
        }
    }
}

Versionamento API e Migrazione dei Token

Durante l'evoluzione delle API, a volte è necessario modificare le strutture dei token. Una strategia di versionamento ben pianificata permette transizioni graduali.

src/EventListener/JWTDecodedListener.phpphp

namespace App\EventListener;

use Lexik\Bundle\JWTAuthenticationBundle\Event\JWTDecodedEvent;

class JWTDecodedListener
{
    public function onJWTDecoded(JWTDecodedEvent $event): void
    {
        $payload = $event->getPayload();
        
        // Verifica versione token per retrocompatibilità
        $version = $payload['token_version'] ?? 1;
        
        if ($version < 2) {
            // Converti struttura token legacy nella nuova
            $payload['permissions'] = $this->migratePermissions($payload);
        }
        
        // Valida IP binding se abilitato
        if (isset($payload['ip'])) {
            $currentIp = $_SERVER['REMOTE_ADDR'] ?? '';
            if ($payload['ip'] !== $currentIp) {
                $event->markAsInvalid();
            }
        }
    }

    private function migratePermissions(array $payload): array
    {
        // Mappa ruoli legacy sulla nuova struttura permessi
        $roles = $payload['roles'] ?? [];
        $permissions = [];
        
        if (in_array('ROLE_ADMIN', $roles)) {
            $permissions = ['read', 'write', 'delete', 'admin'];
        } elseif (in_array('ROLE_USER', $roles)) {
            $permissions = ['read', 'write'];
        }
        
        return $permissions;
    }
}

Configurazione CORS per l'Integrazione Frontend

Il Cross-Origin Resource Sharing deve essere configurato correttamente affinché le applicazioni frontend su altri domini possano accedere all'API. Il NelmioCorsBundle offre una configurazione CORS flessibile.

yaml

# config/packages/nelmio_cors.yaml
nelmio_cors:
    defaults:
        allow_origin: ['%env(CORS_ALLOW_ORIGIN)%']
        allow_methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'OPTIONS']
        allow_headers: ['Content-Type', 'Authorization', 'X-Requested-With']
        expose_headers: ['Link', 'X-Total-Count']
        max_age: 3600
    paths:
        '^/api/':
            allow_origin: ['https://frontend.example.com']
            allow_credentials: true

L'opzione allow_credentials: true è necessaria quando l'applicazione frontend invia cookie o header Authorization.

Validazione Input e Gestione degli Errori

Un'API sicura valida rigorosamente tutti gli input. Il componente Validator di Symfony insieme ad API Platform offre validazione dichiarativa.

src/Dto/CreateUserRequest.phpphp

namespace App\Dto;

use Symfony\Component\Validator\Constraints as Assert;

class CreateUserRequest
{
    #[Assert\NotBlank]
    #[Assert\Email]
    public string $email;

    #[Assert\NotBlank]
    #[Assert\Length(min: 12, minMessage: 'La password deve avere almeno 12 caratteri.')]
    #[Assert\Regex(
        pattern: '/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)/',
        message: 'La password deve contenere maiuscole, minuscole e numeri.'
    )]
    public string $password;

    #[Assert\NotBlank]
    #[Assert\Length(max: 100)]
    public string $name;
}

Le risposte di errore dovrebbero essere formattate in modo consistente senza esporre dettagli interni.

src/EventListener/ExceptionListener.phpphp

namespace App\EventListener;

use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpKernel\Event\ExceptionEvent;
use Symfony\Component\HttpKernel\Exception\HttpExceptionInterface;
use Symfony\Component\Validator\Exception\ValidationFailedException;

class ExceptionListener
{
    public function __construct(private string $environment) {}

    public function onKernelException(ExceptionEvent $event): void
    {
        $exception = $event->getThrowable();
        
        $response = match(true) {
            $exception instanceof HttpExceptionInterface => new JsonResponse(
                ['error' => $exception->getMessage()],
                $exception->getStatusCode()
            ),
            $exception->getPrevious() instanceof ValidationFailedException => new JsonResponse(
                ['error' => 'Errore di validazione', 'details' => $this->formatValidationErrors($exception->getPrevious())],
                422
            ),
            default => new JsonResponse(
                ['error' => $this->environment === 'prod' ? 'Errore interno del server' : $exception->getMessage()],
                500
            ),
        };
        
        $event->setResponse($response);
    }

    private function formatValidationErrors(ValidationFailedException $exception): array
    {
        $errors = [];
        foreach ($exception->getViolations() as $violation) {
            $errors[$violation->getPropertyPath()] = $violation->getMessage();
        }
        return $errors;
    }
}

Pronto a superare i tuoi colloqui su Symfony?

Pratica con i nostri simulatori interattivi, flashcards e test tecnici.

Esplora Symfony

Domande Frequenti nei Colloqui sulla Sicurezza API Symfony

Come si invalida un token JWT prima della sua scadenza?

I JWT sono stateless e non possono essere revocati direttamente. Le strategie di implementazione includono: blacklisting dei token in Redis usando il JTI (JWT ID), token di breve durata (5-15 minuti) combinati con refresh token, o memorizzazione di una versione del token nel profilo utente che viene incrementata al cambio password.

Qual è la differenza tra autenticazione e autorizzazione in Symfony?

L'autenticazione verifica l'identità dell'utente (chi sei?) attraverso la verifica delle credenziali o dei token. L'autorizzazione determina quali azioni un utente autenticato può eseguire (cosa puoi fare?) attraverso ruoli, Voter e Access Control Rules.

Come si protegge un'API dagli attacchi CSRF?

Le API JWT stateless non sono intrinsecamente vulnerabili al CSRF poiché non utilizzano cookie per l'autenticazione. Quando i refresh token sono memorizzati come cookie HTTP-only, dovrebbe essere impostato il flag SameSite=Strict, e l'endpoint di refresh dovrebbe richiedere un token CSRF aggiuntivo dal body della richiesta.

Quali sono le best practice per memorizzare i segreti JWT?

I metodi adatti alla produzione includono: variabili d'ambiente (mai committare nel codice), servizi di gestione segreti (AWS Secrets Manager, HashiCorp Vault), e coppie di chiavi RSA con chiavi private che esistono solo sul server. Le chiavi private dovrebbero avere permessi file 600.

Come si implementa il versionamento API con JWT?

Il versionamento può avvenire attraverso path URL (/api/v1/, /api/v2/) o header (Accept: application/vnd.api.v1+json). I claim del token possono includere un identificatore di versione per garantire retrocompatibilità durante la migrazione.

Conclusione

Symfony fornisce un'infrastruttura di sicurezza completa per le REST API. Il LexikJWTAuthenticationBundle in combinazione con il componente Security di Symfony abilita un'autenticazione JWT robusta. Il rate limiting protegge dagli attacchi brute force, mentre i Voter consentono un controllo degli accessi granulare. La corretta configurazione di CORS, validazione input e gestione consistente degli errori completano un'architettura di sicurezza API pronta per la produzione.

Sicurezza REST API Symfony: Autenticazione JWT e Best Practice 2026

Installazione di LexikJWTAuthenticationBundle in Symfony 7.2

Configurazione dei Firewall Security per l'Autenticazione API

Creazione di un'Entity User con Hashing della Password

Implementazione dei Refresh Token per Sessioni Prolungate

Controllo degli Accessi Basato sui Ruoli con Attributi

Rate Limiting per la Protezione da Attacchi Brute Force

Versionamento API e Migrazione dei Token

Configurazione CORS per l'Integrazione Frontend

Validazione Input e Gestione degli Errori

Pronto a superare i tuoi colloqui su Symfony?

Domande Frequenti nei Colloqui sulla Sicurezza API Symfony

Conclusione

Sapresti trovare il bug in Symfony?

Articoli correlati

Sicurezza REST API Symfony nel 2026: OAuth2, Rate Limiting e Domande per Colloqui

API Platform con Symfony nel 2026: Architettura e Domande per Colloqui Tecnici

API Platform GraphQL con Symfony: Schema, Mutation e Domande da Colloquio 2026