Busca en todas las páginas de la documentación
Un límite de confianza es cualquier punto en un sistema donde el control pasa de algo en lo que no confías completamente a algo en lo que sí confías: una solicitud HTTP desde la internet pública que llega a tu manejador de rutas, una ruta de archivo construida a partir de la entrada del usuario que toca el sistema de archivos, un cuerpo de respuesta de una API de terceros que aterriza en la memoria de tu proceso.
La sección de seguridad de Node cubre mucho terreno específico: validación de solicitudes, encabezados de seguridad, protecciones SSRF, contaminación de prototipos, escaneo de dependencias.
Cada una de esas páginas resuelve un problema concreto.
Esta página es el marco que las conecta: cada uno de esos controles existe para proteger un límite de confianza específico, y comprender los límites primero hace que los controles individuales se sientan como un sistema coherente en lugar de una lista de verificación arbitraria.
Conceptos básicos de seguridad recorre la versión práctica de estos controles; trata esta página como el modelo que explica por qué están ahí y por qué el orden y las capas importan.
Cada solicitud que tu proceso Node maneja comenzó en algún lugar que no controlas: un navegador, un cliente móvil, un remitente de webhook, otro servicio, una herramienta CLI que alguien escribió contra tu API.
En el momento en que los datos de esa solicitud cruzan a tu código (se lee un encabezado, se analiza un cuerpo, se desestructura una cadena de consulta), ha cruzado un límite de confianza.
Los backends de Node suelen tener más de estos límites de lo que los desarrolladores suponen inicialmente:
child_process, donde la entrada sin escape se convierte en inyección de comandos.node_modules, que se ejecuta con los mismos privilegios que tu propio código en el instante en que se importa.Una analogía útil es un aeropuerto en lugar de una sola puerta cerrada.
Un pasajero cruza varios puntos de control independientes (mostrador de boletos, control de seguridad, embarque en la puerta), y cada uno asume que el punto de control anterior pudo haber pasado algo por alto.
El control de seguridad no omite su trabajo porque el mostrador de boletos ya verificó una identificación; vuelve a verificar según su propia preocupación, más específica.
Eso es defensa en profundidad: capas independientes, cada una haciendo su propio trabajo, ninguna de ellas confiando en que una capa anterior ya lo manejó por completo.
El principal es simplemente "quién o qué está haciendo esta solicitud" (un usuario, una cuenta de servicio, un llamador no autenticado), y cada cruce de límite debe evaluarse en términos de lo que ese principal tiene realmente permitido hacer, no solo si la solicitud parece bien formada.
El orden en que se ejecutan las defensas importa tanto como las defensas que existen.
Una verificación de límite que se ejecuta después de que los datos que se supone que debe proteger ya se han utilizado no es una verificación de límite, es una autopsia.
El orden convencional para una solicitud HTTP es: autenticar el principal, autorizar la acción específica, validar la forma de la entrada y luego ejecutar la lógica de negocio.
Invertir los pasos dos y tres es un error común y sutil: validar la forma de una carga útil antes de confirmar que el llamador siquiera tiene permiso para enviarla consume CPU en solicitudes que siempre ibas a rechazar, y en peores casos filtra información (un error de validación detallado) a un principal que no debería recibir ninguna respuesta.
Fallo-cerrado es el valor predeterminado de diseño que esto implica: cuando una verificación no puede completarse (una base de datos está caída, un token no puede verificarse, falta un valor de configuración), la respuesta segura es denegar, no pasar a "confiar en ello".
// fallo-cerrado: el estado desconocido se trata como "no permitido"
function isAuthorized(check: () => boolean | undefined): boolean {
try {
return check() === true; // undefined o error lanzado -> false
} catch {
return false;
}
}Ese fragmento parece trivial, pero la propiedad que codifica no lo es: una excepción o un resultado ambiguo se convierte en una denegación, nunca en un paso accidental.
El código de fallo-abierto (donde un error en la verificación de autorización se resuelve accidentalmente como "permitido") es una de las causas raíz más comunes detrás de los incidentes de control de acceso, y rara vez es intencional; generalmente es un try/catch que traga un error y por defecto devuelve true.
La superficie de ataque es la suma de cada punto de cruce de límite que expone tu código: cada ruta, cada campo que acepta un cuerpo de solicitud, cada paquete de terceros que se ejecuta.
Reducir la superficie de ataque (menos campos aceptados, menos rutas permisivas, menos dependencias) a menudo es una victoria de seguridad mayor que añadir otra capa de verificaciones a una superficie ya grande, porque un control que no se necesita no puede ser mal configurado.
Los límites de confianza no permanecen fijos una vez que los dibujas; cambian a medida que una arquitectura evoluciona, y cada cambio necesita su propia revisión.
Dividir un monolito en servicios convierte las llamadas a funciones internas en llamadas HTTP entre principales que solían confiar implícitamente entre sí; "es un servicio interno" no es lo mismo que "es un principal de confianza", y las arquitecturas de confianza cero tratan el tráfico interno con el mismo escepticismo que el tráfico externo exactamente por esta razón.
Añadir una capa de caché o una cola también introduce un nuevo límite: los datos escritos por un servicio y leídos por otro han cruzado un límite de confianza incluso si ambos servicios son "tuyos", porque el retraso en la implementación, la desviación del esquema o un productor comprometido pueden hacer que esos datos no sean confiables en el momento en que se consumen.
El límite de dependencias merece una atención particular porque es el menos visible.
Una sola npm install puede incorporar cientos de paquetes transitivos, cada uno ejecutándose con privilegios completos de Node.js (acceso al sistema de archivos, acceso a la red, process.env) en el momento en que se importan, no solo cuando se llaman sus funciones exportadas.
Escaneo de dependencias cubre las herramientas para esto; el modelo mental a tener en cuenta aquí es que una dependencia no es "probablemente buena porque es popular"; la popularidad afecta la probabilidad de que un ataque a la cadena de suministro se detecte rápidamente, no si es posible.
| Capa de Defensa | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Validación de entrada (Zod, esquema) | Rechaza datos mal formados antes de que lleguen a la lógica; fácil de probar | Tan buena como el esquema; no verifica la autorización | Cada límite que acepta datos externos |
| Verificaciones AuthN/AuthZ | Confirma la identidad y el permiso antes de que se ejecute cualquier cosa | Añade un viaje de ida y vuelta a la red/DB si no se almacena en caché cuidadosamente | Cada solicitud, antes de la validación y la lógica de negocio |
| Encabezados de seguridad (Helmet, CSP) | Mitiga clases de ataques del lado del cliente (XSS, clickjacking) con casi cero código | No protege el servidor en sí; fácil de configurar mal un CSP hasta hacerlo inútil | Cualquier servicio que sirva contenido renderizado por el navegador |
| Protecciones de egreso/SSRF | Impide que las solicitudes salientes lleguen a la infraestructura interna | Añade latencia (resolución de DNS, verificaciones de rango de IP) a cada llamada saliente | Cualquier endpoint que obtenga una URL proporcionada por el usuario |
| Escaneo de dependencias | Detecta paquetes conocidos-vulnerables y recién marcados como maliciosos | No puede detectar un día cero o un paquete que es malicioso desde el primer día | Pipeline de CI, en cada cambio de dependencia |
Ninguna fila de esa tabla es "la" solución; cada una protege un límite diferente, y una revisión de incidentes generalmente revela que faltaba exactamente una capa, no que todo el modelo falló.
helmet() hace que mi aplicación sea segura." Establece un puñado de encabezados de respuesta HTTP que mitigan clases específicas de ataques del lado del cliente; no dice nada sobre la autorización, la validación de entrada o la cadena de suministro de tu propia dependencia.npm audit limpio significa que mi árbol de dependencias no tiene riesgo de cadena de suministro." Las herramientas de auditoría señalan vulnerabilidades conocidas y divulgadas; un paquete malicioso recién publicado o una cuenta de mantenedor comprometida no produce ninguna señal de auditoría hasta que alguien lo informa.Cualquier punto donde los datos o el control pasan de un dominio que no controlas (un cliente, una API de terceros, una dependencia) a un código que lo trata como entrada confiable. Los backends de Node suelen tener varios: la propia solicitud HTTP, el sistema de archivos, los argumentos del subproceso, las llamadas de red salientes, las dependencias instaladas y la configuración/secretos.
Porque la defensa en profundidad asume que cualquier capa individual puede ser omitida, mal configurada o simplemente no estar al tanto de una invariante posterior. Una puerta de enlace valida la forma y los límites de velocidad; generalmente no puede imponer la autorización a nivel de objeto (si este llamador puede acceder a este recurso específico), lo que debe ocurrir más cerca de los datos.
Significa que una verificación de autorización o validación que encuentra un error, un tiempo de espera o un resultado ambiguo deniega la solicitud por defecto, en lugar de pasar a "permitido". Concretamente: envuelve las verificaciones de permisos para que las excepciones se resuelvan en false, nunca en true, y nunca omitas una verificación solo porque una dependencia de la que depende no esté disponible temporalmente.
Porque cada paso es más barato de rechazar y filtra menos información que el siguiente. Autenticar primero significa que un llamador no autenticado nunca llega a un error de validación detallado; validar antes de autorizar corre el riesgo de hacer un trabajo real (y potencialmente exponer detalles del esquema) para una solicitud que nunca iba a ser permitida, independientemente de su forma.
A menudo más arriesgado, porque es menos visible. Un paquete de terceros se ejecuta con los mismos privilegios a nivel de proceso que tu propio código en el momento en que se importa (sistema de archivos, red, variables de entorno), y un servicio Node típico incorpora cientos de dependencias transitivas que nunca revisaste directamente.
Un límite de confianza es un punto de cruce específico (una ruta, una llamada al sistema de archivos, una obtención saliente). La superficie de ataque es la suma total de todos esos puntos de cruce en tu servicio: cada campo aceptado, cada ruta, cada dependencia. Reducir la superficie (menos campos aceptados, menos dependencias) reduce la cantidad de límites que tienes que defender.
Porque "red interna" describe la topología, no la confianza. Un servicio interno comprometido, una solicitud mal enrutada o un error en el código de un equipo par pueden enviar datos no confiables a través de lo que parece una llamada puramente interna; las arquitecturas de confianza cero formalizan esto al nunca tratar la ubicación de la red como prueba de legitimidad.
No, la estratificación debe seguir los límites que realmente existen para una ruta de código dada, no aplicarse uniformemente por precaución. Las verificaciones redundantes y no coordinadas añaden latencia y costos de mantenimiento sin añadir profundidad real si todas verifican lo mismo de la misma manera.
Protegen un límite específico: el navegador que renderiza tu respuesta, no tu servidor. Una Content-Security-Policy estricta limita lo que una inyección XSS exitosa puede hacer en el lado del cliente, pero no hace nada por los límites del lado del servidor como la validación de entrada o la autorización.
Porque es realmente el límite de egreso fallando: tu servidor, actuando como un principal de confianza en tu red interna, es engañado para hacer una solicitud a una dirección a la que el llamador original nunca podría llegar directamente (como un endpoint de metadatos en la nube). La solución tiene forma de límite: validar y restringir lo que tu servidor obtendrá en nombre de otra persona, no solo "sanear la cadena de URL".
El privilegio mínimo limita cuánto daño puede hacer un fallo de límite una vez que ocurre. Incluso con una validación de entrada perfecta, un usuario de la base de datos con acceso de escritura a cada tabla convierte una inyección SQL en una catástrofe en lugar de un incidente contenido; el privilegio mínimo es la capa que asume que todas las demás capas podrían fallar eventualmente.
No, los escáneres (auditorías de dependencias, análisis estático, verificadores de encabezados) verifican patrones conocidos y controles conocidos, pero no pueden decirte si has identificado cada límite en una nueva característica. Mapear los límites es un paso de diseño; el escaneo es un paso de verificación para los controles que ya decidiste poner allí.
Enumera cada lugar donde los datos externos ingresan al proceso (campos HTTP, rutas de archivo, argumentos de subprocesos, URL salientes, configuración) y luego, para cada uno, pregunta qué sucede actualmente si esos datos son maliciosos o mal formados en lugar de bien comportados. Las brechas suelen aparecer como "asumimos que eso no podía suceder" en lugar de como una biblioteca faltante.
Versiones de la pila: Esta página fue escrita para Node.js 24 LTS y TypeScript 5.6+.
Revisado por Chris St. John·Última actualización: 15 jul 2026