Pages d'erreur verbeuses et stack traces en production
Lorsqu'une exception non gérée ou une requête vers une route inexistante déclenche la vue d'erreur de débogage d'un framework en production, elle peut offrir à un attaquant une carte de votre serveur : chemins de fichiers, numéros de ligne, versions des bibliothèques et parfois variables d'environnement. La solution consiste à renvoyer des réponses d'erreur génériques aux utilisateurs tout en journalisant les détails complets uniquement dans un service côté serveur contrôlé par votre équipe.
Ce que c’est
Chaque framework web embarque une vue d'erreur de débogage — la page d'exception jaune de Django, l'écran Ignition de Laravel, l'overlay de développement de Next.js, le dump d'exception par défaut d'Express. Elles sont précieuses pendant le développement, mais volontairement désactivées dans les builds de production. Le risque vient des pages d'erreur de framework restées actives parce que le mode debug n'a pas été désactivé, ou de gestionnaires d'erreurs personnalisés qui renvoient des objets d'exception bruts directement dans le corps de la réponse.
AppSafe détecte les erreurs verbeuses en demandant un chemin qui ne devrait pas exister sur votre site. Si le corps de la réponse correspond à des motifs courants de pages d'erreur de framework — tracebacks Python, dumps d'exception Node.js, détails d'exception .NET, chemins Rails.root ou similaires —, le résultat est signalé avec une sévérité moyenne dans la catégorie Gestion des erreurs et résilience.
Pourquoi ça compte
Une stack trace révèle le langage et la version du framework, la structure interne des répertoires de votre app, le fichier et la ligne exacts qui ont échoué, et la chaîne d'appels qui y a mené. Associées à une base de CVE, ces informations raccourcissent le délai entre la découverte et un exploit ciblé — surtout pour les vulnérabilités connues de versions précises de frameworks ou de bibliothèques.
Les pages de débogage peuvent aussi inclure dans leur rendu des données de requête, des variables d'environnement partielles ou des fragments SQL, divulguant par inadvertance des saisies utilisateur ou des valeurs internes au serveur qui ne devraient jamais atteindre un navigateur.
Comment corriger
Dans les routes API et les Route Handlers Next.js, interceptez explicitement les exceptions, journalisez l'erreur complète côté serveur et renvoyez un statut générique à l'appelant.
// 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 });
}
}En production, Next.js affiche pages/500.tsx (ou app/error.tsx dans l'App Router) pour les erreurs non gérées. Remplissez-la avec un message convivial — sans détails techniques — et branchez un service de monitoring d'erreurs comme Sentry pour capturer la véritable exception.
Pour toute erreur qui échappe à la couche applicative, nginx peut remplacer toutes les réponses 5xx par une page statique avant qu'elles n'atteignent le navigateur.
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
internal;
}FAQ
Next.js affiche-t-il des stack traces dans les builds de production ?
L'overlay de développement est déjà supprimé en production. Le vrai risque vient des Route Handlers ou routes API personnalisés qui interceptent une exception et la sérialisent directement dans la réponse — ce que le framework n'empêchera pas de lui-même.
Comment AppSafe détecte-t-il les erreurs verbeuses ?
Il demande une URL qui n'existe pas sur votre site et analyse le corps de la réponse à la recherche d'expressions comme 'Traceback (most recent call last)', 'Stack trace:', 'Unhandled Runtime Error', 'Exception Details:' et d'autres marqueurs similaires issus des frameworks Python, Node.js, PHP, Java, Ruby et .NET.
Ma page 404 n'affiche pas de stack trace, mais AppSafe l'a quand même signalée. Pourquoi ?
Le scanner compare un large ensemble de motifs, dont certains apparaissent dans des réponses d'erreur partielles ou expurgées. Vérifiez si des noms de classes d'exception, des chemins de fichiers internes ou des identifiants de framework apparaissent quelque part dans le corps de vos réponses 404 ou 500 — même dans un commentaire ou un élément masqué.
Votre app est-elle concernée ?
AppSafe détecte ce problème et des dizaines d’autres en un seul scan gratuit.
Scanner mon app gratuitementGuides liés
Les source maps en production divulguent votre code source
Les fichiers .map livrés donnent accès à votre code source original.
Méthodes HTTP dangereuses : comment TRACE, PUT et DELETE sont annoncées
Une réponse OPTIONS qui liste TRACE ou DELETE révèle plus que nécessaire.
Introspection GraphQL publique : pourquoi c'est un problème et comment la désactiver
Une seule requête renvoie tout votre schéma. Désactivez-la en production.