Severidad MediaManejo de errores y resiliencia

Páginas de error detalladas y stack traces en producción

Cuando una excepción no controlada o una petición a una ruta inexistente activa la vista de error de depuración de un framework en producción, puede entregar a un atacante un mapa de tu servidor: rutas de archivos, números de línea, versiones de librerías y, a veces, variables de entorno. La solución es devolver respuestas de error genéricas a los usuarios y registrar los detalles completos solo en un servicio del lado del servidor que controle tu equipo.

Qué es

Todos los frameworks web incluyen una vista de error de depuración: la página amarilla de excepciones de Django, la pantalla Ignition de Laravel, el overlay de desarrollo de Next.js, el volcado de excepciones por defecto de Express. Son muy valiosas durante el desarrollo, pero se desactivan deliberadamente en los builds de producción. El riesgo está en las páginas de error del framework que siguen activas porque no se desactivó el modo debug, o en manejadores de error personalizados que devuelven objetos de excepción en bruto directamente en el cuerpo de la respuesta.

AppSafe detecta errores detallados solicitando una ruta que no debería existir en tu sitio. Si el cuerpo de la respuesta coincide con patrones típicos de páginas de error de frameworks (tracebacks de Python, volcados de excepciones de Node.js, detalles de excepciones de .NET, rutas Rails.root o similares), el hallazgo se reporta con severidad media en Manejo de errores y resiliencia.

Por qué importa

Un stack trace expone el lenguaje y la versión del framework, la estructura interna de directorios de tu app, el archivo y la línea exactos que fallaron y la cadena de llamadas que llevó hasta ahí. Combinada con una base de datos de CVE, esa información acorta el tiempo entre el descubrimiento y un exploit dirigido, sobre todo para vulnerabilidades conocidas en versiones concretas de frameworks o librerías.

Las páginas de depuración también pueden incluir datos de la petición, variables de entorno parciales o fragmentos SQL en la salida, filtrando sin querer entradas de usuario o valores internos del servidor que nunca deberían llegar a un navegador.

Cómo solucionarlo

Nunca devuelvas excepciones en bruto al cliente

En las rutas de API y Route Handlers de Next.js, captura las excepciones explícitamente, registra el error completo en el servidor y devuelve un estado genérico a quien hizo la llamada.

// 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 });
  }
}

Configura una página de error personalizada

Next.js renderiza pages/500.tsx (o app/error.tsx en el App Router) para los errores no controlados en producción. Rellénala con un mensaje amable, sin detalles técnicos, y conecta un servicio de monitorización de errores como Sentry para capturar la excepción real.

Intercepta en la capa del proxy

Para cualquier error que escape de la capa de la aplicación, nginx puede sustituir todas las respuestas 5xx por una página estática antes de que lleguen al navegador.

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

Preguntas frecuentes

¿Next.js muestra stack traces en los builds de producción?

El overlay de desarrollo ya está suprimido en producción. El riesgo real son los Route Handlers o rutas de API personalizados que capturan una excepción y la serializan directamente en la respuesta, algo que el framework no evitará por sí solo.

¿Cómo comprueba AppSafe si hay errores detallados?

Solicita una URL que no existe en tu sitio y analiza el cuerpo de la respuesta en busca de frases como 'Traceback (most recent call last)', 'Stack trace:', 'Unhandled Runtime Error', 'Exception Details:' y marcadores similares de frameworks de Python, Node.js, PHP, Java, Ruby y .NET.

Mi página 404 no muestra ningún stack trace, pero AppSafe la marcó igualmente. ¿Por qué?

El escáner busca un conjunto amplio de patrones, algunos de los cuales aparecen en respuestas de error parciales o censuradas. Comprueba si aparecen nombres de clases de excepción, rutas internas de archivos o identificadores del framework en algún lugar del cuerpo de tu respuesta 404 o 500, incluso en un comentario o un elemento oculto.

¿Tu app está afectada?

AppSafe verifica este y docenas de problemas más en un solo escaneo gratis.

Escanear mi app gratis

Del blog

PHP2Shell está siendo explotado: cómo comprobar si tu app está expuesta

Dos bugs críticos en el propio PHP pasaron de "parche publicado" a "explotado activamente" en cuestión de días. Cómo saber si algo de lo que alojas usa una versión afectada y qué hacer hoy mismo.