Manejo de Errores y Seguridad en Aplicaciones Node.js
Resumen
¿Cómo gestionar errores de seguridad en tu aplicación de manera eficiente?
En el mundo del desarrollo web, la gestión de errores es una cuestión crítica no solo para la estética sino también para la seguridad de una aplicación. Es vital impedir que potenciales atacantes obtengan información sobre el servidor o la aplicación a través de errores no manejados. Este contenido ofrece una guía práctica para gestionar errores en aplicaciones Node.js con Express, mejorando así la seguridad y utilidad de las respuestas de error.
¿Cómo centralizar la gestión de errores?
Centralizar la gestión de errores significa consolidar todos los manejadores de errores en un solo archivo o módulo para simplificar su gestión y control. En este caso, el archivo error.js es creado para este propósito.
¿Cómo integrar el manejador de errores en Express?
Una vez que se tiene un archivo dedicado para la gestión de errores, el siguiente paso es integrarlo dentro de Express como el último middleware. Esto garantiza que pueda capturar cualquier error que no haya sido manejado previamente.
// Integrar el manejador de errores en Expressconst errors =require('./network/errors');// Otros middlewaresapp.use(errors);
¿Cómo personalizar los errores para mejorar las respuestas?
La personalización de errores permite que una aplicación responda de manera coherente y específica a cada tipo de error. Aquí se utiliza una estructura de errores personalizada para establecer códigos de estado y mensajes más útil.
// Crear una estructura de error personalizadafunctionCustomError(message, statusCode){const error =newError(message); error.statusCode= statusCode;return error;}module.exports=CustomError;
A su vez, al implementarlo en funcionalidad como autenticación, cambiar new Error por CustomError mejora significativamente la interpretación de los errores.
// Personalizar errores en funcionalidades específicasconstCustomError=require('../utils/error');functionauthHandler(req, res, next){const authorized =false;// Simulación de una condiciónif(!authorized){returnnext(CustomError('No tienes privilegios para hacer esto',401));}next();}
Consejos prácticos:
Recordar la ubicación del middleware: Al integrar el middleware de errores, asegúrate de que sea el último que uses para evitar interrupciones en el flujo de ejecución.
Manejo diferencial de errores: No todos los errores deben responder con un estado 500 (Error del Servidor Interno), personaliza usando códigos como 401 (No Autorizado), 403 o 404 según la situación.
Ampliación según necesidad: Si requieres registrar detalles adicionales del error para fines de auditoría, puedes expandir la forma en que estructuras los errores en CustomError.
Implementar estas estrategias no solo mejora la seguridad de tu aplicación al esconder detalles potencialmente sensibles, sino que también mejora la experiencia del usuario al ofrecer respuestas más precisas y comprensibles en caso de errores. ¡Continúa explorando y perfeccionando estas prácticas para fortalecer tus aplicaciones!
Manejo de Errores y Seguridad en Aplicaciones Node.js
Esta clase es magistral. Cada vez me doy cuenta de que no conozco nada jajaja
Hasta ahora no me habia puesto a pensar en lo peligroso que podria ser que el cliente reciba esos mensajes con la trazabilidad del error
les comparto mi implementación del middleware de error
Para el que quiera implementar esto debe obtener las credenciales de sentry en su website y ademas configurar correctamente el proyecto para que sentry funcione. Muy buena herramienta por cierto. https://sentry.io/welcome/
en el curso de backend con node y el de passport js, se trabaja con un libreria @hapi, la cual tiene un modulo para el manejo de errores que es @hapi/boom y @hapi/joi para validaciones, con unas simples lineas se le da manejo al error, es muy practico, lo mismo con las validaciones.
buen consejo, coincido a pleno , y la arquitectura de las folders es distinta también, a mi entender es mas fácil de entender , la estructura de folders usada por el profe @nicobytes
La clase es buena aunque se agradecería que no repita nombres de archivos ya que eso genera mucha confusión. En utils tenemos error.js y en network tenemos errors.js
Por si alguien mas le da el mismo error que a mi, "app use requires a middleware" La solucion es la darle require se le coloca llaves:
const{errors}=require('../network/errors');
Usando custom error en lugar de throw new Error()
pero ¿Cómo sabe el middleware network/errors.js que está recibiendo un error? ¿cómo recibe ese parámetro err?
exactamente la misa pregunta ~
Por el error fisrt callback, eso lo enseñan en fundamentos de nodejs
creando la fucnion error en la carpeta util, ya no haria falta el error.js de la carpeta network?
Fantástico ahora mi código está mucho más organizado con los cursos de carlos, que fácil es aprender Node con él.
La forma en la que estructura el codigo esta genial
Entiendo el uso del helper lo que no entiendo es porqué repetimos en network/response la misma logica del status code y status msg.
Ahora tenemos todos los errores centralizados dentro de utils/error, con lo cual no deberiamos llamar a network error sino llamar a utils/error y es este error catcheado por network error.
Podemos modificar entonces network/response la function error
El middleware tambien va a responder cuando se visite una ruta que no este definida con un mensaje de error y cualquier otra expecion que surgiera por una mala implementacion nuestra. La logica de network a la que te refieres son errores controlados por nosotros, cuando se solicita el recurso de las rutas que estamos controlando. Pero como comente, si visitaran otra ruta, o surgiera un error no controlado va a ser interceptado por ese ultimo middleware. Antes de este se podria agregar un middleware mas para generar por ejemplo un log de errores.
-./utils/error.js: Este se encarga de generar un nuevo error dentro de nuestra api. Ej: en registrar nuevo usuario si falta el parámetro username generamos un nuevo error con esta utilidad.
-./network/errors.js: Este es un middleware que se va a encargar de capturar todos los errores que hayamos generados en el api.
Al ser un middleware lo trabaja separado de lo que es la lógica del response, cada vez que se genera el error con throw error() debemos llamar a next() dentro del catch de la promesa para que el middleware maneje ese error.
¿como funciona el next?
next es un callback, cuando lo llamas pasa a la siguiente middleware en orden.
Definitivamente, muy buena clase
Fijesé que igual le devuelve un error:false cuando debería ser true, supongo que se solucionara en adelante.
Eso se cambia en la carpeta network>response.js
en exports.success y exports.error
donde error: false debe cambiar a error: true para exports.error
Estoy super confundido con el archivo "secure" en users, hay una función "checkAuth" que recibe el parametro "action" y adentro "middleware" con los argumentos "req, res, next". Si mal no entiendo, middleware se ejecuta cuando se devuelve al invocar checkAuth desde router.put, pero el único argumento es lo que afecta al switch, ¿los parámetros req, res y next cómo le llegan al middleware?
Creo que esto sucede porque es un middleware de autenticación y por lo tanto, next() permite que se ejecute el middleware de network que le sigue. Si no estoy en lo correcto, que alguien me corrija por favor!
sacando brillo a el mundo magico de nodejs
Fantástico ahora mi código está mucho más organizado con los cursos de carlos, que fácil es aprender Node con él.
Excelente clase!
¿Para qué sirve esta carpeta utils?
Cuando modulamos nuestro proyectos podemos llegar a tener funciones muy genéricas, que tal vez podamos reutilizar y que no sean tan grandes como para hacer un módulo. Esas funciones podemos meterlas en esta carpeta.
Solo es una práctica en la modulación de tus proyectos.
gracias
No estoy seguro que sea, estoy en el minuto 4:27 del video, mientras al profesor le sale el mensaje No puedes realizar esta acción a mi me sale el mensaje error interno. he revisado los archivos y no encuentro la diferencia.
En consola el error es el correcto
[error] Error: No puedes realizar esta acción
pero no lo veo en el mensaje de postman. error no tiene una propiedad messages, ni code.
Así que me quedan todas las dudas en esa parte. de donde obtiene el valor de messages
Y mostrar el mensaje del error no sería también perjudicial?
Puede ser yo creo que justamente, esta arquitectura te da la posibilidad de eligir que hacer con el error.
En Laravel por ejemplo en entorno de desarrollo retorna todos los errores y cambiando una variable de config los esconde para producción
Se me ocurre que podriamos manejarlo igual. con una variable en config o con el mismo process.env.NODE_ENV