Oculta las trazas de pila a los usuarios con mensajes seguros e ID de error
Oculta las trazas de pila a los usuarios mostrando mensajes seguros e un ID de error. Registra los detalles completos en el servidor para depurar rápido sin exponer secretos.
Por qué no deberían aparecer trazas de pila en producción
Una traza de pila es un informe técnico que muestra dónde se produjo el fallo en tu app y la cadena de llamadas que llevó al error. Es útil para desarrolladores porque puede señalar el archivo y la línea exactos que fallaron.
Para los usuarios, es sólo ruido. No necesitan saber qué función lanzó una excepción para completar un pago, restablecer una contraseña o iniciar sesión. Necesitan un paso siguiente claro, como intentarlo de nuevo, revisar lo que han escrito o contactar con soporte.
Los errores en crudo en producción también pueden revelar más de lo que esperas. Una sola traza de pila puede incluir rutas de archivos del servidor, versiones de librerías, rutas internas, nombres de tablas de base de datos o incluso partes de la petición que provocaron el fallo. Si secretos aparecen en el texto del error (tokens, claves, cadenas de conexión), puedes filtrarlos a cualquiera que desencadene el error.
Cosas comunes que se filtran en trazas de pila y páginas de excepción incluyen:
- Rutas y nombres de carpetas del servidor
- Fragmentos SQL o nombres de tablas
- Versiones de frameworks y paquetes
- Datos de usuario de la petición fallida (correos, IDs y más)
Un patrón más seguro es mostrar un mensaje humano, incluir un ID de error que el usuario pueda compartir y registrar los detalles completos en el servidor.
Qué puede salir mal si muestras errores en crudo
Mostrar trazas de pila a usuarios reales es algo más que desordenado. Puede exponer un mapa de tu app: rutas de archivos, librerías, nombres de funciones y las entradas que provocaron el fallo.
Exposición de seguridad
Los errores en crudo suelen filtrar información que nunca quisiste publicar, especialmente en prototipos hechos rápido.
Eso puede incluir secretos (claves de API, tokens, cadenas de conexión), endpoints internos y rutas de administrador, detalles de la base de datos e información precisa de versiones que facilita explotar vulnerabilidades conocidas.
Filtración de privacidad
Algunos errores muestran la carga útil completa de la petición. Si esa carga incluye correos, direcciones o campos relacionados con pagos, un bug normal puede convertirse en un incidente de datos.
Daño a la confianza y a la conversión
Un usuario que ve un muro de código o una página de error aterradora asume que el producto no es seguro o está incompleto, incluso si el fallo es menor. Abandonan el registro, cancelan una compra o dejan de volver.
Soporte más lento
En lugar de un informe claro como “no pude pagar”, recibes capturas de pantalla de una traza de pila con líneas cortadas y sin pasos para reproducir. Tu equipo pierde tiempo adivinando qué pasó y a qué usuario afectó.
Un patrón simple que funciona: mensaje seguro + ID de error + logs
Para ocultar trazas de pila a los usuarios sin ralentizar la depuración, separa lo que ve el usuario de lo que registras.
- Mensaje para el usuario: una explicación corta y calmada con un paso siguiente claro.
- ID de error: una referencia única ligada a ese fallo.
- Registro en servidor: los detalles completos de la excepción más el contexto necesario para investigar.
Ejemplo de texto:
“Algo salió mal al guardar. Por favor, inténtalo de nuevo. Si sigue ocurriendo, comparte este ID con soporte: ABC123.”
Esta separación da fruto cuando alguien reporta “no puedo iniciar sesión, ID de error 7F2K9.” Buscas en los logs ese ID y ves inmediatamente la excepción real, la ruta y qué entradas la desencadenaron, sin exponer nada de eso al usuario.
Comportamiento en desarrollo vs producción
En desarrollo, las páginas de error detalladas pueden estar bien porque aceleran el trabajo local.
En producción:
- muestra un mensaje seguro y un ID de error
- conserva la traza completa en los logs del servidor
Cómo escribir mensajes de error seguros que los usuarios entiendan
Un mensaje de error seguro debería hacer dos cosas:
- Explicar lo ocurrido en palabras sencillas.
- Decir al usuario qué hacer a continuación.
Céntrate en el objetivo del usuario, no en tus internos. “No pudimos guardar tus cambios” ayuda. “NullReferenceException en UserController” no.
Una plantilla simple
La mayor parte del buen texto de error encaja en esta forma:
- Qué pasó: una frase corta, sin términos técnicos.
- Siguiente paso: una acción clara.
- Ayuda extra: “Inténtalo de nuevo en un minuto” o “Contacta con soporte con el ID de error ABC123.”
Mantenlo neutral. Evita culpar (“Has hecho algo mal”) y evita frases vagas (“Algo salió mal”) a menos que añadas un paso siguiente.
Ejemplos
En lugar de:
“500 Internal Server Error. Stack trace: ...”
Usa:
“No pudimos iniciar tu sesión. Revisa tu correo y contraseña e inténtalo de nuevo. Si sigue ocurriendo, contacta con soporte con el ID de error Q7F2.”
Para guardar cambios:
“Tus cambios no se guardaron. Actualiza la página e inténtalo de nuevo. ID de error K3M9.”
Un problema, una acción. Si das tres opciones a la vez, muchos usuarios se bloquean.
Cómo generar y anexar un ID de error
Un ID de error es el puente entre un mensaje amigable y los detalles técnicos.
Cómo debería ser el ID
Procura que sea:
- fácil de copiar (a menudo 8 a 12 caracteres mostrados al usuario)
- difícil de adivinar (no incremental, no sólo una fecha)
- lo bastante único para evitar colisiones
Buenas opciones incluyen UUIDv4 o ULID. Muchos equipos almacenan el ID completo en los logs pero muestran una forma abreviada en la interfaz.
También puedes añadir un prefijo para ayudar al triage, como AUTH- o PAY-, siempre que el resto del ID sea aleatorio.
Dónde mostrarlo
Muestra el ID donde el usuario pueda encontrarlo: una página de error, un toast o una pantalla de acción fallida. Mantén la colocación consistente para que soporte pueda decir: “Busca el ID de error y envíanoslo.”
Asegúrate de que el mismo ID aparezca en tus logs del servidor
Genera el ID una vez por fallo y llévalo por todo el flujo de error:
- inclúyelo en el cuerpo de la respuesta (o en la UI de error)
- opcionalmente inclúyelo en un encabezado de respuesta para clientes API
- escríbelo en los logs del servidor junto con los detalles completos de la excepción
- asígnalo a alertas internas para que todos usen la misma referencia
Qué registrar en el servidor (y qué nunca registrar)
El registro de errores en servidor debe facilitar responder: ¿qué pasó?, ¿dónde pasó? y ¿por qué?
Una entrada de log útil suele incluir:
- marca temporal y entorno (prod, staging)
- ruta y método (por ejemplo, POST /signin) y estado de respuesta
- ID de error
- un identificador de usuario o de sesión si está permitido (mejor un ID interno, no un correo)
- un resumen seguro de entradas (conteos, tipos, campos no sensibles)
También captura los detalles de la excepción en el servidor: el tipo de excepción, el mensaje, la traza de pila y cualquier información de causa raíz (por ejemplo, qué servicio externo falló por timeout). Para trabajos en segundo plano, añade el nombre del job y el intento de reintento.
Sé estricto con lo que nunca registras. No registres contraseñas, códigos de un solo uso, números completos de tarjeta, tokens de auth, claves de API, cookies privadas ni secretos de variables de entorno. Si registras texto proporcionado por el usuario, considera truncarlo y eliminar patrones de tokens evidentes.
Paso a paso: implementar errores seguros en tu app
Trata el manejo de errores en producción como una pequeña característica, no como un ajuste de última hora.
- Apaga la salida detallada en producción. Desactiva el modo debug y las páginas de excepción detalladas. Revisa la configuración del hosting también, no sólo la del app.
- Añade un manejador catch-all en el backend. Convierte excepciones inesperadas en una respuesta con forma segura.
- Genera un ID de error por fallo. Devuélvelo al cliente y regístralo en el servidor.
- Registra un evento estructurado. Incluye el ID de error más la traza completa y el contexto.
- Forza un error de prueba. Confirma que la UI sólo muestra el mensaje seguro y que los logs contienen los detalles que necesitas.
Para la prueba forzada, usa algo predecible: un endpoint con un campo requerido ausente, una ruta de sesión expirada o un throw temporal en una ruta no crítica. Verifica dos cosas: la respuesta nunca incluye detalles internos y la entrada de log es fácil de encontrar por el ID de error.
Errores comunes que evitar
Desplegar con settings de debug
Una de las formas más fáciles de filtrar detalles es lanzar con modo debug (o páginas de excepción verbosas) activado. Suele ocurrir tras un hotfix apresurado o cuando falta una variable de entorno en producción.
IDs de error adivinables
Evita IDs como 12345 o 2026-01-20-15:03. Los IDs predecibles pueden filtrar información de tiempo y volumen y son más fáciles de abusar.
Mensajes amigables sin logging
Capturar un error y devolver un mensaje calmado es útil sólo si también registras lo que ocurrió. Si no, recibes tickets de soporte sin datos.
Registrar demasiado
El error contrario es volcar cuerpos de petición completos, cookies y tokens en los logs. Eso crea riesgo de privacidad y hace que los logs sean más difíciles de usar.
Lista rápida antes de lanzar
Antes de una release, provoca algunos fallos comunes en staging (o en producción con una cuenta de prueba): contraseña incorrecta, registro faltante, sesión expirada, llamada a API fallida.
- La UI muestra un mensaje en lenguaje claro y un ID de error.
- Puedes pegar ese ID en la búsqueda de logs y encontrar el evento exacto rápido.
- No aparece texto de excepción crudo en la página, toast, consola o cuerpo de la respuesta en la red.
- Los logs no contienen secretos, tokens, contraseñas, cookies ni campos completos de pago.
- Las respuestas de error siguen una forma consistente entre web y API.
Después haz una revisión rápida de privacidad: lee una entrada de log de error de principio a fin y pregúntate, “Si se compartiera esta captura, ¿expondría algo de lo que nos arrepentiríamos?”
Ejemplo: un error de inicio de sesión manejado correctamente
Un usuario intenta iniciar sesión y falla.
En producción, el usuario debería ver algo como:
“No pudimos iniciar tu sesión. Por favor, inténtalo de nuevo en un minuto. Si sigue ocurriendo, contacta con soporte con el ID de error AUTH-9F3A2C1D.”
Por tu parte, registras un único evento detallado ligado al mismo ID. Ese ID se convierte en la referencia compartida que conecta una experiencia de usuario tranquila con una depuración rápida.
Siguientes pasos: hacer la depuración más rápida sin exponer detalles
Una vez que las trazas de pila estén ocultas, asegúrate de que tu equipo siga avanzando rápido.
Crea una práctica simple de soporte: pide el ID de error y una breve reproducción de lo que hizo el usuario (página, botón, hora y qué esperaba). Eso convierte “se rompió” en algo accionable.
Añade alertas básicas para que los errores repetidos no pasen desapercibidos. Incluso un seguimiento ligero por ruta y tipo de error te ayuda a detectar picos.
Si heredaste un prototipo generado por IA, este también es un buen momento para buscar riesgos de producción relacionados que suelen venir juntos: secretos expuestos, manejo de errores inconsistente y flujos de autenticación frágiles.
Si quieres una segunda opinión, FixMyMess (fixmymess.ai) ofrece una auditoría de código gratuita y puede señalar dónde siguen filtrándose errores crudos o datos sensibles, y luego ayudar a implantar un manejo de errores más seguro en producción.
Preguntas Frecuentes
Why is showing a stack trace in production a bad idea?
Porque confunden a los usuarios y pueden filtrar detalles sensibles. Una traza de pila suele incluir rutas de archivos, rutas internas, versiones de paquetes y, en ocasiones, partes de la petición que falló, lo que puede facilitar a atacantes o exponer datos privados.
What should users see instead of a raw error page?
Muestra un mensaje calmado que explique el problema desde la perspectiva del usuario y ofrezca un único paso claro a seguir, además de un ID de error que puedan compartir con soporte. Mantén los detalles técnicos completos sólo en los logs del servidor.
How do stack traces create security risk?
Puede revelar exactamente cómo está construida tu aplicación y dónde tiene debilidades, incluyendo versiones de frameworks, endpoints internos y detalles de la base de datos. En desarrollos apresurados, incluso puede exponer secretos como tokens o cadenas de conexión si aparecen en el texto del error.
Can stack traces leak user data too?
Algunas páginas de excepción y logs incluyen la carga útil completa de la petición o los datos introducidos. Si eso contiene correos, direcciones, identificadores o campos relacionados con pagos, un fallo normal puede convertirse en un incidente de exposición de datos.
What’s the simplest way to generate a good error ID?
Usa un identificador aleatorio y difícil de adivinar y créalo una vez por fallo. UUIDs o ULIDs funcionan bien; puedes mostrar una versión corta a los usuarios y almacenar el valor completo en los logs para buscar y correlacionar.
Where should the error ID appear in the UI?
Colócalo en cualquier lugar donde el usuario lo vea durante el fallo: una página de error, un mensaje emergente (toast) o un mensaje junto al formulario. Mantén la ubicación consistente para que soporte pueda preguntar: “¿Qué ID de error ves?”
What should I include in server-side error logs?
Registra el ID de error, la marca temporal, el entorno, la ruta/método, el código de estado y los detalles completos de la excepción, incluida la traza de pila. Añade contexto seguro como un ID interno de usuario o de sesión cuando esté permitido, para poder reproducir y trazar el impacto sin exponer datos personales.
What should I never log when debugging production errors?
No registres contraseñas, códigos de un solo uso, números completos de tarjetas, tokens de autenticación, claves de API, cookies privadas ni secretos sin procesar de variables de entorno. Si capturas texto proporcionado por el usuario, mantenlo al mínimo y considera truncarlo para reducir filtraciones accidentales.
Should error handling be different in development vs production?
En desarrollo, las páginas de error detalladas aceleran la depuración local. En producción, desactiva la salida de depuración y devuelve siempre una respuesta segura con un ID de error, mientras registras los detalles completos en los logs del servidor para poder arreglar los problemas con rapidez.
How can I test that stack traces are truly hidden in production?
Provoca un fallo controlado en una ruta no crítica y confirma que la interfaz sólo muestra el mensaje amistoso y el ID de error. Luego busca ese ID en los logs para asegurarte de que capturaste la traza de pila y el contexto, y verifica que la respuesta y la consola del cliente no incluyan texto de la excepción en crudo.