Node.js
Seguridad en aplicaciones Node.js: validación, secretos, dependencias, permisos, inyección, traversal, deserialización, límites de recursos y configuración segura.
La seguridad de una aplicación Node.js depende de sus , permisos y límites de recursos. HTTPS o una validación aislada no vuelven segura toda la aplicación.
entrada externa
↓ validar y limitar
lógica autorizada
↓ usar APIs seguras
recurso protegido
↓ registrar sin exponer secretos
respuesta mínimaIncluye:
Valida tipo, formato, rango, tamaño y relación con el usuario autenticado. Validar sintaxis no reemplaza autorización.
No concatenes entrada con un directorio base. Genera nombres internos y restringe el directorio de trabajo.
import path from "node:path";
const base = path.resolve("uploads");
const target = path.resolve(base, requestedName);
if (!target.startsWith(`${base}${path.sep}`)) {
throw new Error("Invalid path");
}Symlinks y condiciones de carrera requieren permisos mínimos, operaciones atómicas y aislamiento adicional.
// Inseguro: la shell interpreta metacaracteres.
exec(`convert ${userInput}`);Prefiere execFile o spawn con argumentos separados y una lista permitida de operaciones. No pases input externo a una shell sin una necesidad excepcional y controles estrictos.
Una request puede ser válida y aun así agotar CPU, memoria, sockets o thread pool.
Si el servidor consulta una URL proporcionada por un usuario, puede alcanzar servicios internos o metadata de infraestructura.
DNS puede cambiar entre comprobación y conexión; diseña la defensa en la capa de conexión, no solo en el string.
No incluyas tokens, contraseñas, cookies, cuerpos sensibles ni variables completas en logs. Centraliza redacción y clasifica campos.
Un secreto en process.env sigue siendo accesible para el proceso y herramientas con permisos suficientes. Rota, limita acceso y evita heredarlo innecesariamente a child processes.
npm audit detecta ciertos avisos conocidos; no garantiza ausencia de código malicioso ni fallos propios.
Usa node:crypto y algoritmos establecidos. No inventes cifrado, tokens o password hashing.
import { randomBytes, timingSafeEqual } from "node:crypto";
const token = randomBytes(32).toString("base64url");Para contraseñas utiliza una función específica de password hashing con parámetros actualizables. Una función hash rápida como SHA-256 sola no es apropiada.
timingSafeEqual exige buffers de igual longitud y solo resuelve una parte de los ataques de timing.
TLS cifra y autentica el canal cuando la validación de certificados es correcta. No protege contra autorización incorrecta, SQL injection, SSRF o datos sensibles en logs.
No desactives rejectUnauthorized en producción para resolver certificados.
El Permission Model es estable en líneas modernas soportadas y se activa explícitamente:
node --permission \
--allow-fs-read=./config \
--allow-fs-write=./tmp \
app.jsPuede restringir filesystem, red, child processes, workers, addons, WASI e inspector según la versión y los flags disponibles.
process.permission.has("fs.read", configPath);Es una defensa adicional para código confiable: evita accesos accidentales, pero la documentación oficial aclara que no es un sandbox frente a código malicioso.
Limitaciones relevantes:
Mantén además usuario sin privilegios, restricciones del sistema/container, secrets mínimos y revisión de dependencias.
Objetos construidos desde input pueden modificar claves especiales o afectar merges inseguros. Usa validación, esquemas, objetos sin prototipo cuando aporte y librerías actualizadas.
Nunca evalúes código recibido. JSON.parse no ejecuta código, pero el objeto resultante sigue siendo no confiable.
¿Por qué validar que una URL empiece por https:// no evita SSRF?
Porque un hostname HTTPS puede resolver a una dirección privada, redirigir a otro destino o cambiar su resolución. También debe controlarse el destino efectivo y la conexión.
Rendimiento y profiling enseña a medir costos antes de optimizar.