Gravità MedioGestione degli errori e resilienza

Pagine di errore dettagliate e stack trace in produzione

Quando un'eccezione non gestita o una richiesta a una route inesistente attiva la vista di errore di debug di un framework in produzione, può consegnare a un attaccante una mappa del tuo server: percorsi dei file, numeri di riga, versioni delle librerie e talvolta variabili d'ambiente. La soluzione è restituire agli utenti risposte di errore generiche e registrare i dettagli completi solo in un servizio lato server controllato dal tuo team.

Che cos'è

Ogni framework web include una vista di errore di debug — la pagina di eccezione gialla di Django, la schermata Ignition di Laravel, l'overlay di sviluppo di Next.js, il dump di eccezione predefinito di Express. Sono preziose in sviluppo, ma vengono deliberatamente disattivate nelle build di produzione. Il rischio sono pagine di errore del framework che restano attive perché la modalità debug non è stata disattivata, o error handler personalizzati che restituiscono oggetti di eccezione grezzi direttamente nel corpo della risposta.

AppSafe rileva gli errori dettagliati richiedendo un percorso che non dovrebbe esistere sul tuo sito. Se il corpo della risposta corrisponde a pattern tipici delle pagine di errore dei framework — traceback Python, dump di eccezioni Node.js, dettagli di eccezioni .NET, percorsi Rails.root o simili — la segnalazione viene riportata con severità media nella categoria Gestione degli errori e resilienza.

Perché è importante

Uno stack trace espone il linguaggio e la versione del framework, la struttura interna delle directory dell'app, il file e la riga esatti in cui si è verificato l'errore e la catena di chiamate che ci ha portato. Abbinata a un database di CVE, questa informazione accorcia il tempo tra la scoperta e un exploit mirato — soprattutto per vulnerabilità note in specifiche versioni di framework o librerie.

Le pagine di debug possono includere anche dati della richiesta, variabili d'ambiente parziali o frammenti SQL nell'output, facendo trapelare involontariamente input degli utenti o valori interni del server che non dovrebbero mai raggiungere un browser.

Come risolverlo

Non restituire mai eccezioni grezze al client

Nelle route API e nei Route Handler di Next.js, intercetta esplicitamente le eccezioni, registra l'errore completo lato server e restituisci al chiamante uno stato generico.

// app/api/example/route.ts
export async function GET() {
  try {
    // ... handler logic ...
  } catch (err) {
    console.error(err); // logs stack trace to your server/monitoring only
    return new Response("Internal Server Error", { status: 500 });
  }
}

Configurare una pagina di errore personalizzata

In produzione Next.js mostra pages/500.tsx (o app/error.tsx nell'App Router) per gli errori non gestiti. Inserisci un messaggio amichevole — senza dettagli tecnici — e collega un servizio di monitoraggio degli errori come Sentry per catturare l'eccezione reale.

Intercettare a livello di proxy

Per qualsiasi errore che sfugge al livello applicativo, nginx può sostituire tutte le risposte 5xx con una pagina statica prima che raggiungano il browser.

error_page 500 502 503 504 /50x.html;
location = /50x.html {
  root /usr/share/nginx/html;
  internal;
}

FAQ

Next.js mostra gli stack trace nelle build di produzione?

L'overlay di sviluppo è già soppresso in produzione. Il vero rischio sono Route Handler o route API personalizzati che intercettano un'eccezione e la serializzano direttamente nella risposta — qualcosa che il framework da solo non impedisce.

Come verifica AppSafe la presenza di errori dettagliati?

Richiede un URL che non esiste sul tuo sito e analizza il corpo della risposta cercando frasi come 'Traceback (most recent call last)', 'Stack trace:', 'Unhandled Runtime Error', 'Exception Details:' e marcatori simili dei framework Python, Node.js, PHP, Java, Ruby e .NET.

La mia pagina 404 non mostra uno stack trace ma AppSafe l'ha comunque segnalata. Perché?

Lo scanner confronta un ampio insieme di pattern, alcuni dei quali compaiono in risposte di errore parziali o oscurate. Controlla se nomi di classi di eccezione, percorsi di file interni o identificatori del framework compaiono da qualche parte nel corpo della risposta 404 o 500 — anche in un commento o in un elemento nascosto.

La tua app è interessata?

AppSafe controlla questo e decine di altri problemi in un'unica scansione gratuita.

Scansiona la mia app gratis

Dal blog

PHP2Shell è sotto attacco: come verificare se la tua app è esposta

Due bug critici in PHP stesso sono passati da "patch rilasciata" a "sfruttati in the wild" in pochi giorni. Come capire se qualcosa che ospiti usa una versione vulnerabile, e cosa fare oggi.