Errores, validación y seguridad básica

1.Tipos de error en un servidor

En un servidor, los errores no son una excepción: son parte del trabajo. Conviene distinguir dos familias:

El cliente debe recibir siempre una respuesta útil y coherente, y tú, un registro de lo que pasó. Lo que nunca debe ocurrir es que el servidor se caiga o que la petición se quede colgada.

try/catch en rutas async

Ya conoces try/catch con await. Úsalo cuando puedas recuperarte del error en esa misma ruta:

import { readFile } from "node:fs/promises";

app.get("/config", async (req, res) => {
  try {
    const texto = await readFile("config.json", "utf8");
    res.json(JSON.parse(texto));
  } catch (error) {
    if (error.code === "ENOENT") {
      return res.json({});   // no hay archivo: usamos valores por defecto
    }
    throw error;               // cualquier otro error sube al manejador general
  }
});

Fíjate en el throw error: si no sabes arreglar el problema, relánzalo para que lo trate el manejador de errores central, en vez de tragártelo.

2.Un manejador de errores central

En la lección 4 viste que un middleware con cuatro parámetros es un manejador de errores. En Express 5, además, si una función async lanza un error o rechaza una promesa, Express lo envía solo a ese manejador. Así puedes escribir rutas limpias:

export function crearErrorHttp(estado, mensaje) {
  const error = new Error(mensaje);
  error.status = estado;
  return error;
}

export function manejarErrores(err, req, res, next) {
  const estado = err.status ?? 500;
  const esServidor = estado >= 500;

  if (esServidor) console.error(err);   // el detalle va al registro, no al cliente

  res.status(estado).json({
    error: esServidor ? "Error interno del servidor" : err.message,
  });
}

import { crearErrorHttp, manejarErrores } from "./errores.js";

app.get("/tareas/:id", async (req, res) => {
  const tarea = await buscarTarea(Number(req.params.id));   // si falla, llega al manejador
  if (!tarea) throw crearErrorHttp(404, "Tarea no encontrada");
  res.json(tarea);
});

// ... resto de rutas ...

app.use((req, res) => res.status(404).json({ error: "Ruta no encontrada" }));
app.use(manejarErrores);   // siempre el último

Para que un error no tumbe todo el proceso, Node también permite escuchar fallos globales, pero eso se ve en proyectos grandes. Lo importante ahora es que cada ruta tenga una salida segura. Más detalles en la guía de manejo de errores de Express.

3.Validar la entrada

La regla de oro: todo lo que llega de fuera es sospechoso. Puede venir vacío, con el tipo equivocado, enorme o con mala intención. Validar significa comprobar los datos antes de usarlos y rechazar con 400 si no cumplen.

export function validarTarea(datos) {
  const errores = [];

  if (typeof datos?.titulo !== "string" || datos.titulo.trim() === "") {
    errores.push("titulo obligatorio");
  } else if (datos.titulo.length > 100) {
    errores.push("titulo demasiado largo");
  }
  if (datos.hecha !== undefined && typeof datos.hecha !== "boolean") {
    errores.push("hecha debe ser booleano");
  }
  return errores;
}

app.post("/tareas", (req, res) => {
  const errores = validarTarea(req.body);
  if (errores.length > 0) {
    return res.status(400).json({ error: "Datos inválidos", detalles: errores });
  }
  // ... crear la tarea con datos ya comprobados
});

Devolver una lista de problemas (no solo el primero) le ahorra al cliente enviar la petición una y otra vez. Practica con este editor:

4.CORS y buenas prácticas básicas

Cuando una página web en https://mi-sitio.com intenta llamar a tu API en https://api.mi-sitio.com, el navegador bloquea la respuesta por la política del mismo origen, salvo que tu servidor diga explícitamente que lo permite. Ese permiso se llama CORS (Cross-Origin Resource Sharing) y se da con cabeceras de respuesta. Hay una explicación completa en MDN.

La forma más simple en Express es el paquete oficial cors:

npm install cors

import cors from "cors";

// Solo estos sitios podrán llamar a tu API desde un navegador
app.use(cors({ origin: ["https://mi-sitio.com", "http://localhost:5173"] }));

Un uso peligroso es cors() sin opciones (permite cualquier origen): vale mientras pruebas, pero en producción limita la lista.

Lista de buenas prácticas básicas

5.Errores frecuentes

• Devolver el stack trace o el mensaje interno al cliente: revela cómo funciona tu servidor.
• Responder 200 con un cuerpo de error: usa el código de estado correcto.
• Tragarse el error en un catch vacío: el problema desaparece del registro y nadie se entera.
• No validar el cuerpo y confiar en que «el cliente enviará lo correcto».
• Creer que CORS protege tu API: solo afecta a los navegadores.
• Dejar cors() abierto a cualquier origen en producción.
• Poner el manejador de errores antes de las rutas: debe ser el último app.use.

6.Glosario