Protezione CSRF in React e nelle configurazioni API

Il Cross-Site Request Forgery (CSRF) è un attacco in cui un sito web dannoso induce il browser dell'utente a inviare una richiesta autenticata alla propria API. Poiché il browser allega automaticamente i cookie alle richieste, il server non può distinguere tra una richiesta legittima proveniente dalla propria applicazione e una richiesta contraffatta proveniente dal sito dell'attaccante.

I cookie sono la causa principale della vulnerabilità CSRF. Quando un utente accede alla propria applicazione, il cookie di sessione viene memorizzato nel browser. Quando visita la pagina dell'attaccante, quest'ultimo può attivare l'invio di un modulo o una richiesta fetch alla propria API, e il browser include automaticamente il cookie di sessione, autenticando così la richiesta dannosa.

L'attributo cookie SameSite indica ai browser quando includere i cookie nelle richieste cross-site. Ha tre valori: Lax (il valore predefinito nei browser moderni: blocca le richieste POST cross-site, ma consente le richieste GET), Strict (blocca tutte le richieste cross-site, incluse le navigazioni GET) e None (consente le richieste cross-site, ma richiede il flag HTTPS Secure).

SameSite=Lax blocca le richieste cross-site POST, PUT, DELETE e PATCH, ovvero i metodi usati per le mutazioni. Se l'API usa GET solo per le letture e POST per tutte le mutazioni, SameSite=Lax previene di fatto il CSRF per le SPA nei browser moderni. Oggi questa è la mitigazione di base su cui fanno affidamento la maggior parte delle applicazioni.

Il pattern del doppio invio del cookie è una mitigazione CSRF in cui il server imposta un token CSRF casuale in un cookie non HttpOnly. Il client legge il valore di questo cookie e lo include in un'intestazione personalizzata della richiesta (ad esempio X-CSRF-Token). Il server verifica che il valore dell'intestazione corrisponda a quello del cookie. Un attaccante non può leggere il cookie da un'origine diversa e quindi non può impostare l'intestazione corretta.

Il pattern del token sincronizzato genera un token CSRF univoco per ogni sessione utente sul server. Nei moduli HTML, il token viene inserito in un campo nascosto. Per le chiamate API di una SPA, il token viene fornito tramite un endpoint o un meta tag e inviato in un'intestazione personalizzata. Il server convalida il token a ogni richiesta che modifica lo stato.

Una SPA React che memorizza il proprio JWT in memoria o in localStorage e lo invia in un'intestazione Authorization: Bearer non è vulnerabile al CSRF classico. Gli attacchi CSRF sfruttano l'autenticazione basata sui cookie: la pagina di un attaccante non può impostare intestazioni personalizzate nelle richieste cross-origin a causa delle restrizioni CORS, quindi non può contraffare l'intestazione Authorization.

Le richieste cross-origin semplici (invio di un modulo POST, caricamento di un'immagine) non consentono intestazioni personalizzate. Solo le richieste che passano dal preflight CORS possono includere intestazioni personalizzate, e le richieste sottoposte a preflight richiedono l'autorizzazione esplicita del server. Un'API che richiede un'intestazione personalizzata (come X-Requested-With: XMLHttpRequest) per tutte le mutazioni è intrinsecamente protetta dagli attacchi CSRF semplici.

CORS controlla quali origini possono leggere la risposta a una richiesta cross-origin. CSRF riguarda quali origini possono effettuare richieste che modificano lo stato. Configurare CORS per limitare le origini non impedisce CSRF: il browser invia comunque la richiesta e il cookie; CORS controlla solo se la risposta è visibile a JavaScript. Un attacco CSRF non ha bisogno di leggere la risposta.

Configuri i cookie di sessione con: HttpOnly: true (impedisce a JavaScript di leggere il cookie, bloccando il furto di token basato su XSS), Secure: true (viene inviato solo tramite HTTPS), SameSite: Lax o Strict (previene CSRF) e un valore appropriato di Max-Age o una scadenza appropriata. Insieme, questi quattro attributi rafforzano significativamente la gestione delle sessioni.

L'App Router di Next.js utilizza le Server Actions, che sono richieste POST. Next.js implementa la protezione CSRF verificando l'header Origin rispetto all'host: le richieste provenienti da origini impreviste vengono rifiutate. Questo controllo integrato, combinato con i cookie di sessione SameSite=Lax, offre una solida protezione CSRF per le mutazioni basate sulle Server Actions.

Quale valore del cookie SameSite blocca le richieste POST cross-site, ma consente le navigazioni GET cross-site?

CSRF sfrutta l'autenticazione basata sui cookie inducendo il browser a inviare richieste cross-site autenticate. SameSite=Lax è la difesa di base nei browser moderni. I pattern Double Submit Cookie e Synchronizer Token offrono una protezione aggiuntiva. Le SPA React che utilizzano JWT negli header Authorization sono intrinsecamente resistenti a CSRF. Anche gli header obbligatori personalizzati e il preflight di CORS contribuiscono a mitigare CSRF. Combini sempre HttpOnly + Secure + SameSite sui cookie di sessione.