Scegliere Next.js è una decisione tecnica con una componente di governance: il framework è open source, ma è creato e governato da Vercel, che vende anche l'hosting gestito di Next.js. Il punto non è se sia un buon framework, ma se i confini tra il progetto e l'azienda siano abbastanza chiari da farsi un'idea dei rischi prima di adottarlo. Parto dall'analisi di Eduardo Bouças, You should know this before choosing Next.js, e aggiungo il mio punto di vista.

Perché la scelta di un framework pesa

Nell'ambito enterprise scegliere una tecnologia significa spesso un impegno pluriennale, con effetti sulle roadmap, sul ritmo di sviluppo, sulla qualità dei deliverable e persino sulla capacità di formare e mantenere un team soddisfatto. Il software open source risponde a queste esigenze in due modi: chiunque può estenderlo o modificarlo per il proprio caso d'uso, e la portabilità permette di spostare l'infrastruttura tra fornitori senza restare vincolati a un vendor.

Non c'è nulla di male nel fatto che un'azienda tragga profitto da un software open source che ha creato, soprattutto se questo finanzia il progetto. Ritengo però che il modello regga nel tempo solo se i confini tra azienda e progetto sono definiti, con aspettative chiare tra manutentori, fornitori di hosting e utenti su come e dove ogni funzionalità possa essere usata.

Dove si pone il problema di trasparenza

Bouças dichiara di lavorare in Netlify, concorrente di Vercel, ed è un'informazione da tenere presente nel leggere le sue critiche. I punti che solleva sono questi:

  • Percorsi di codice riservati a Vercel. L'esempio principale è una modalità interna, la "minimal mode", che permette a Vercel di spostare il middleware sulla propria infrastruttura edge. Un percorso privilegiato di questo tipo, sostiene, mina l'idea di un progetto pienamente aperto.
  • Nessun sistema di adapter. L'output di build di Next.js non è documentato, quindi gli altri provider devono appoggiarsi ad API non ufficiali che possono cambiare senza preavviso. Cloudflare e Netlify sono entrate nel progetto OpenNext per gestire questa situazione.
  • Nessuna modalità serverless ufficiale. Quella precedente è stata rimossa nel 2022 senza sostituto, e ogni provider deve ricostruire la propria implementazione.

Vercel si è mossa dopo le critiche: secondo lo stesso Bouças, il 28 marzo 2025 ha dichiarato che non avrebbe aggiunto nuovi percorsi privilegiati e che avrebbe rimosso o documentato per intero quelli esistenti, come la minimal mode, con l'obiettivo di concludere entro il 2025. Sul fronte degli adapter, le note di rilascio di Next.js 16.2, del 18 marzo 2026, dichiarano stabili le Adapters, una nuova API che permette alle piattaforme di personalizzare il processo di build. È la risposta tecnica a una delle critiche principali.

La vulnerabilità e la gestione dell'evento

Il caso che ha reso il tema concreto è CVE-2025-29927, un bypass del middleware di gravità critica. Next.js usa un header interno, x-middleware-subrequest, per evitare ricorsioni e saltare l'esecuzione del middleware; poiché non era documentato e poteva essere abusato, il middleware poteva essere aggirato, controlli di autenticazione compresi.

Dal postmortem di Vercel risulta:

  • la segnalazione è arrivata il 27 febbraio 2025 e la vulnerabilità è stata confermata il 14 marzo;
  • le versioni corrette sono la 14.2.25 e la 15.2.3, con backport sulla 13.5.9 e sulla 12.3.5;
  • erano esposte le installazioni self-hosted con next start e output: 'standalone'; Vercel, Netlify e Cloudflare Workers non risultavano colpite, perché il routing è separato dal server Next.js;
  • chi non poteva aggiornare doveva filtrare l'header x-middleware-subrequest prima che le richieste raggiungessero il server.

La critica di Bouças riguarda la comunicazione, non il bug in sé. Sostiene che Vercel abbia impiegato otto giorni per avvisare Netlify e che il primo articolo presentasse l'episodio come qualcosa che il proprio firewall avrebbe evitato, salvo poi essere rivisto. Sono sue affermazioni: la versione di Vercel è nel postmortem linkato sopra, e vale la pena leggerle entrambe.

Come scegliere con consapevolezza

La mia conclusione è la stessa dell'articolo originale: la decisione di adottare Next.js, o qualsiasi altro framework, non può fermarsi alle funzionalità. Serve valutare anche trasparenza, governance, approccio alla sicurezza e capacità di reagire nelle situazioni critiche, perché la fiducia nella piattaforma si fonda su questo oltre che sulla qualità del codice. Alcune domande pratiche da porsi prima di partire:

  1. Dove verrà ospitata l'applicazione, e quali funzioni del framework dipendono da quell'hosting?
  2. Se dovessimo cambiare provider tra due anni, quanto costerebbe?
  3. Come ha gestito il progetto, in passato, la divulgazione delle vulnerabilità?
  4. Esistono impegni documentati sulla governance, e vengono rispettati?

Bouças stesso precisa di non voler fermare nessuno dall'usare Next.js: l'obiettivo è scegliere con tutte le informazioni in mano. Condivido.

Fonti: Eduardo Bouças, Vercel, postmortem su CVE-2025-29927.