La biblia de la seguridad en la web

El motor no distingue entre tu consulta y el texto que pegó el atacante: todo llega como una sola instrucción. Con un solo campo mal tratado se extrae la tabla de usuarios completa, se borran registros o se escribe un fichero en el servidor.

Usa consultas parametrizadas o el query builder del ORM, siempre con marcadores de posición. Los identificadores que no se pueden parametrizar (nombre de tabla, columna de ordenación) se resuelven contra una lista blanca cerrada, nunca con el valor recibido.

Un punto y coma, un pipe o unas comillas invertidas convierten tu utilidad de conversión de imágenes en una shell remota. Es la escalada más directa que existe: de un campo de formulario a ejecución de código en el servidor.

Llama al binario sin shell, pasando los argumentos como array (execFile / spawn sin shell:true). Si el valor decide qué se ejecuta, valídalo contra una lista blanca. Ejecutar una shell con texto compuesto por el usuario no tiene una versión segura.

Si el cliente puede enviar un objeto donde esperabas una cadena, cuela operadores del motor. Un password con {"$ne": null} convierte tu comprobación de credenciales en un "cualquier contraseña sirve".

Valida el cuerpo con un esquema estricto (zod, JSON Schema de Fastify) que exija tipos primitivos y rechace propiedades desconocidas. Nunca esparzas el cuerpo recibido dentro del filtro de la consulta.

El motor de plantillas es un intérprete completo. Si el atacante controla la plantilla y no solo los datos, tiene acceso al contexto de ejecución del proceso y de ahí a variables de entorno, secretos y ejecución de código.

La plantilla es siempre una constante del código; el dato del usuario entra únicamente como variable de contexto. Si el producto permite plantillas editables por el cliente, ejecútalas en un motor sin acceso a objetos del lenguaje (sandbox lógico) y con lista blanca de funciones.

Deserializar un objeto arbitrario permite al atacante elegir qué clases se instancian y qué métodos se disparan durante la reconstrucción. Es ejecución de código sin necesitar una vulnerabilidad de memoria.

Transporta datos en formatos sin comportamiento: JSON parseado con JSON.parse y validado contra un esquema. Si necesitas objetos ricos, reconstrúyelos a mano desde campos validados. Nada de eval ni de deserializadores que resucitan tipos por nombre.

Cuando se filtre la base de datos —y las bases de datos se filtran— un hash rápido se rompe a millones de intentos por segundo con hardware barato. Como la gente reutiliza contraseñas, tu fuga se convierte en la fuga del banco de tus usuarios.

Usa un algoritmo diseñado para ser lento y costoso en memoria: argon2id, scrypt o bcrypt, con sal por usuario y parámetros revisados cada año. Guarda el algoritmo y sus parámetros junto al hash para poder migrar sin forzar un reseteo global.

Sin freno, la fuerza bruta y el credential stuffing con listas filtradas son cuestión de tiempo de CPU ajeno. El atacante no necesita romper nada: prueba hasta acertar, y con listas reales acierta.

Limita por cuenta y por IP con retardo creciente, bloqueo temporal y captcha tras varios fallos. Añade segundo factor para roles con privilegios. Registra el evento y alerta cuando una misma IP falla contra muchas cuentas distintas.

Si el identificador anónimo sobrevive al login, quien haya conseguido plantarlo antes (por un enlace o por un dominio hermano) queda dentro de la sesión autenticada de la víctima. Se llama fijación de sesión y no requiere robar nada.

Regenera el identificador de sesión en el login, en el cambio de contraseña y en cualquier cambio de privilegios, e invalida el anterior en el servidor. Marca la cookie como HttpOnly, Secure y SameSite=Lax o Strict.

Un token eterno es una llave que no se puede cambiar. Si se filtra en un log, en una captura o en el historial del navegador, el acceso del atacante dura lo que dure el sistema, y despedir a un empleado no cierra su acceso.

Vida corta para el token de acceso (minutos), refresco rotatorio con detección de reutilización, y una lista de revocación o versión de credencial por usuario que invalide todo lo emitido antes. Cerrar sesión tiene que invalidar en el servidor, no solo borrar en el cliente.

Si aceptas el algoritmo que declara el propio token, el atacante pone alg: none o cambia RS256 por HS256 y firma con tu clave pública, que es información abierta. Se fabrica un token de administrador sin conocer ningún secreto.

Verifica siempre con una lista fija de algoritmos permitidos, y valida además issuer, audience y expiración. Nunca uses decode sin verify para tomar decisiones. Las claves de firma van en el gestor de secretos y rotan.

Mensajes distintos convierten el login en un enumerador de cuentas: el atacante confirma qué correos existen y concentra el ataque solo en los válidos. El mismo problema aparece en el registro y en el "he olvidado mi contraseña".

Una única respuesta genérica ("credenciales inválidas") para todos los casos, y el mismo trabajo de cómputo en ambos caminos: calcula el hash incluso cuando el usuario no existe para que el tiempo no delate. En recuperación, responde siempre "si el correo existe, hemos enviado un enlace".

Cambiar /facturas/1041 por /facturas/1042 no requiere herramientas. Si la consulta solo filtra por id y no por dueño, cualquier usuario autenticado lee, edita o borra los datos de todos los demás. Es la vulnerabilidad número uno en APIs reales.

La comprobación de propiedad va en la consulta, no en un if posterior: filtra siempre por el identificador del sujeto autenticado además del identificador del recurso. Centraliza la decisión en una capa de autorización que no se pueda olvidar por endpoint.

Ocultar un botón no protege nada: el endpoint sigue ahí y se llama con curl. El JavaScript del cliente está en manos del atacante, y con él todas las banderas de rol que hayas dejado en el estado de la aplicación.

El servidor decide y el cliente solo dibuja. Cada endpoint valida rol y permiso por su cuenta, sin depender de por dónde vino la llamada. Lo del frontend es comodidad visual, jamás control.

Si el registro o el perfil aceptan un campo rol y lo persisten, cualquiera se convierte en administrador con una línea de curl. Lo mismo con empresaId: se salta el aislamiento entre clientes.

Los campos que otorgan privilegio no se aceptan nunca desde la petición: se derivan del token o los asigna un flujo administrativo con su propia autorización y su registro de auditoría. Usa listas de campos permitidos por endpoint y por rol.

Lo interno acaba expuesto: un balanceador mal configurado, un ingress nuevo o una migración a la nube publican esa ruta. La seguridad por desconocimiento de la URL dura hasta el primer escaneo de directorios.

Deniega por defecto: el middleware exige autenticación en todo salvo en una lista explícita y corta de rutas públicas. Las rutas de administración y de servicio llevan además autorización propia y, si aplica, restricción de red.

Una sola consulta sin el filtro de tenant mezcla los datos de dos clientes. En un producto vendido a varias empresas, eso no es un bug: es una brecha contractual y de protección de datos que se ve en pantalla.

Aplica el aislamiento en una capa que no se pueda saltar: ámbito por defecto en el ORM, políticas de fila en la base de datos (RLS) o un repositorio que reciba siempre el contexto del tenant. Prohíbe las consultas crudas sin ese filtro y cúbrelo con pruebas automáticas.

Un secreto en git está en cada clon, en cada fork y en el historial para siempre; borrarlo del último commit no lo borra. Los bots rastrean repositorios públicos y usan las claves en minutos.

Los secretos van por variable de entorno o gestor de secretos, y el fichero de ejemplo lleva solo nombres, no valores. Añade escaneo de secretos en el gancho de pre-commit y en el pipeline. Si uno se filtró, la única respuesta válida es rotarlo.

DES, RC4 y el modo ECB están rotos en la práctica: ECB deja ver patrones del texto original en el cifrado. Un esquema casero sin autenticación permite además que el atacante modifique el mensaje cifrado sin que lo notes.

Usa cifrado autenticado estándar de la biblioteca del sistema: AES-256-GCM o ChaCha20-Poly1305, con nonce único por mensaje y claves gestionadas fuera del código. Para transporte, TLS 1.2 o superior con suites modernas.

Math.random es un generador predecible pensado para simulaciones, no para secretos. Con unas pocas muestras se reconstruye su estado y se predicen los siguientes valores: el enlace de recuperación de otra persona se adivina en lugar de robarse.

Usa un generador criptográficamente seguro (crypto.randomBytes o crypto.randomUUID) con al menos 128 bits de entropía, y dale al token de recuperación una caducidad corta y un solo uso.

La comparación de cadenas corta en el primer carácter distinto, así que tarda un poco más cuantos más caracteres iniciales acierta el atacante. Medido muchas veces, ese microsegundo permite reconstruir el token carácter a carácter.

Compara en tiempo constante con crypto.timingSafeEqual sobre búferes de la misma longitud, o compara hashes de igual tamaño de ambos valores. Aplica lo mismo a tokens de API, firmas de webhook y códigos OTP.

En una red compartida, cualquiera en el mismo camino lee y modifica el tráfico en claro. Basta una redirección inicial sin cifrar para que un atacante mantenga a la víctima en HTTP y capture la sesión entera.

HTTPS obligatorio en todo el dominio, redirección permanente desde HTTP y cabecera HSTS con preload. Cookies con el atributo Secure. El cifrado también aplica entre servicios internos y hacia la base de datos.

La página de error de depuración entrega el mapa completo: rutas del sistema de ficheros, versiones, fragmentos de código, consultas y a veces variables de entorno con credenciales. Es reconocimiento gratis para el atacante.

NODE_ENV en producción, trazas solo al log interno y al cliente un mensaje genérico con un identificador de correlación. Verifica la configuración efectiva en el entorno desplegado, no solo en el fichero de ejemplo.

Un /metrics abierto revela volumen de negocio y rutas internas; un Swagger abierto entrega el catálogo completo de endpoints y parámetros; un panel de administración abierto es directamente la entrada.

Todo lo operativo va detrás de autenticación y, cuando sea posible, restringido por red o VPN. La documentación pública de la API se publica deliberadamente y recortada, nunca por defecto.

Reflejar el Origin recibido y permitir credenciales equivale a dejar que cualquier web lea las respuestas autenticadas de tus usuarios desde su navegador. El atacante monta una página y roba datos de quien la visite estando logueado.

Lista blanca explícita de orígenes, comparación exacta (ojo con los sufijos: midominio.com.atacante.com), y credentials solo con esos orígenes concretos. Si la API es realmente pública, entonces no lleva credenciales.

Sin Content-Security-Policy, un XSS que aparezca mañana se ejecuta sin resistencia. Sin X-Content-Type-Options, el navegador adivina el tipo y convierte un fichero subido en un script. Sin X-Frame-Options o frame-ancestors, tu panel se enmarca en una web ajena para clickjacking.

Aplica un paquete de cabeceras seguras (helmet o equivalente) y define una CSP concreta, sin comodines ni unsafe-inline, y HSTS. Que la política sea real y no una cabecera vacía: revísala en la respuesta desplegada.

El navegador interpreta como marcado lo que le des. Un comentario, un nombre o un campo de perfil con etiquetas se convierte en código que corre con la sesión de quien lo lea: roba la sesión, cambia el correo de la cuenta y actúa en nombre de la víctima.

Usa textContent, o el escapado automático del framework (interpolación de React, Angular o Vue). Si de verdad necesitas HTML enriquecido, pásalo por un saneador con lista blanca (DOMPurify) y refuérzalo con una CSP estricta.

Dentro de un bloque de script el escapado de HTML no sirve: basta cerrar la cadena o la propia etiqueta para salir al contexto de código. Es la forma más común de que un escapado "que ya estaba puesto" no proteja nada.

Pasa los datos al cliente como JSON en un elemento con type="application/json" y léelos con JSON.parse, o por atributos data- escapados como HTML. El escapado depende del contexto: HTML, atributo, URL y JavaScript no se escapan igual.

Un enlace con javascript: o con data:text/html ejecuta código al pulsarlo, aunque hayas escapado el HTML correctamente. Un src remoto además filtra a terceros quién visita tu página.

Valida que la URL empiece por http: o https: (parseándola, no con una comparación de texto), y para enlaces externos añade rel="noopener noreferrer". Si el destino se guarda, valídalo al escribir y al pintar.

Todo lo que hay en localStorage lo lee cualquier script de la página, incluidos los de terceros y el que entre por un XSS. Una cookie HttpOnly no es accesible desde JavaScript, así que un XSS ya no se lleva la sesión de recuerdo.

Cookie HttpOnly, Secure y SameSite para la sesión, con protección CSRF acompañando. Si el arquitectura obliga a un token en el cliente, que sea de vida muy corta, con refresco rotatorio y ámbito mínimo.

El navegador adjunta la cookie automáticamente, también cuando la petición la origina una web ajena. Una página maliciosa envía un formulario a tu endpoint y la víctima, autenticada, transfiere dinero o cambia su correo sin enterarse.

Token anti-CSRF por sesión y por formulario, verificado en el servidor, más cookies SameSite=Lax o Strict. En APIs con token en cabecera Authorization el riesgo desaparece, pero entonces no debe aceptarse también la cookie como alternativa.

Un GET se dispara desde una etiqueta de imagen, un prefetch del navegador o un rastreador. Además queda escrito en logs, historiales y referers, con sus parámetros incluidos. Un enlace de borrado por GET se activa solo.

Verbo según el efecto: GET solo lee y es idempotente; POST, PUT, PATCH y DELETE para lo que cambia estado, con protección anti-CSRF. Los datos sensibles van en el cuerpo, nunca en la ruta ni en la query.

Tu servidor está dentro de la red privada, así que se usa como proxy para alcanzar lo que el atacante no puede: bases de datos internas, paneles sin autenticar, servicios en localhost. La respuesta vuelve envuelta en tu propia API.

Lista blanca de dominios y esquemas permitidos, resolución del nombre y comprobación de que la IP resultante no es privada, de bucle local ni de enlace local, y esa comprobación aplicada tras cada redirección. Sin redirecciones automáticas y con tiempo de espera corto.

La dirección de metadatos de la nube devuelve credenciales temporales del rol de la instancia. Un SSRF que la alcance no roba datos: roba la identidad del servicio y con ella el acceso a todo lo que ese rol puede tocar.

Bloquea el rango de enlace local por firewall o egress, exige la versión con token del servicio de metadatos, y da al rol de la instancia el mínimo permiso posible. Las llamadas salientes de la aplicación pasan por un proxy con lista blanca.

Con suficientes ../ se sale del directorio previsto y se lee cualquier fichero que el proceso pueda abrir: configuración, claves privadas, la base de datos SQLite. En escritura, se sobreescriben ficheros del sistema.

No aceptes rutas: acepta un identificador y resuélvelo contra un catálogo. Si es inevitable, normaliza con path.resolve y verifica que el resultado sigue dentro del directorio base antes de abrir. Decodifica una sola vez y rechaza secuencias sospechosas en lugar de limpiarlas.

Ambos los elige el cliente. Un fichero llamado foto.png con contenido de script y Content-Type falseado pasa cualquier comprobación basada en el nombre. Si acaba en un directorio que ejecuta código, es ejecución remota.

Valida el contenido real (número mágico), fija un límite de tamaño y una lista blanca corta de tipos, renombra el fichero a un identificador generado por ti conservando solo la extensión permitida, y reprocesa las imágenes para descartar cargas embebidas.

Compartir dominio significa compartir cookies y origen: un HTML o un SVG subido ejecuta scripts con acceso a la sesión de tus usuarios. Y si el directorio es el mismo que sirve la aplicación, el servidor puede acabar interpretando lo subido.

Guarda fuera de la raíz web, sirve desde un dominio o bucket separado, con Content-Type fijado, X-Content-Type-Options: nosniff y Content-Disposition: attachment para lo que no sea imagen. Entrega mediante URLs firmadas y de vida corta.

Una entidad externa hace que el parser lea ficheros locales o pida URLs internas mientras interpreta el documento. Sirve para leer /etc/passwd, para SSRF y para tumbar el proceso con una expansión recursiva.

Desactiva DTD y entidades externas en el parser, o cambia a JSON con esquema. Aplica lo mismo a los formatos que llevan XML dentro: documentos ofimáticos, SVG, feeds y SOAP.

Sin lockfile, cada despliegue puede traer código distinto del que probaste. Un mantenedor comprometido o un paquete con nombre parecido al que querías entra en producción sin que nadie apruebe nada.

Commitea el lockfile, instala con el modo reproducible (npm ci) y revisa las dependencias nuevas antes de aceptarlas: quién la mantiene, cuánto pesa el árbol que arrastra, si de verdad la necesitas. Menos dependencias es menos superficie.

Una CVE publicada es una guía de explotación con exploit incluido. La ventana entre la publicación y el escaneo masivo se mide en horas, y tu versión vulnerable está anunciada en la propia respuesta del servidor.

Auditoría automática en cada pipeline que rompa la construcción ante severidad alta, inventario de componentes (SBOM) actualizado y un responsable con plazo para parchear. Suscríbete a los avisos de lo que realmente usas.

Un postinstall de cualquier paquete del árbol se ejecuta con las variables del entorno de construcción. Si ahí viven las claves de producción, un solo paquete comprometido las exfiltra sin tocar tu código.

Separa los secretos por etapa y por entorno, no expongas los de producción en trabajos de construcción o de pruebas, usa credenciales de vida corta e identidad federada, y bloquea los scripts de instalación cuando puedas (--ignore-scripts).

Los logs se copian a herramientas de terceros, se ven en pantallas compartidas y los lee gente que no tendría acceso a esos datos. Un token en un log es una credencial válida guardada en un sitio sin control de acceso equivalente.

Lista de campos a enmascarar aplicada en el propio logger (password, token, authorization, cookie, tarjeta, documento), registro del identificador en lugar del dato, y retención limitada. Nunca vuelques el cuerpo completo de una petición sin filtrar.

El mensaje del motor revela nombres de tablas y columnas, el dialecto y la consulta que falló. Es exactamente el mapa que le falta al atacante para afinar una inyección que iba a ciegas.

Un manejador de errores único que traduce cualquier excepción a un código y un mensaje neutros para el cliente, con un identificador de correlación, y que deja el detalle solo en el log interno.

Sin registro de quién hizo qué y cuándo, un incidente no se puede investigar ni acotar: no sabes qué datos salieron ni desde cuándo. Y sin alertas, la intrusión se descubre meses después y por un tercero.

Registra autenticaciones, cambios de permisos, accesos a datos personales, exportaciones y operaciones administrativas, con actor, recurso, origen y momento, en un almacén que la aplicación no pueda modificar. Añade alertas sobre patrones anómalos.

Sin límite, el mismo endpoint sirve para enumerar usuarios, adivinar códigos, vaciar tu base de datos con paginación y arruinarte la factura de la nube. También lo convierte en un objetivo trivial de denegación de servicio.

Límite por identidad y por IP, con ventana deslizante y respuesta 429 con Retry-After. Límites más estrictos en login, recuperación de contraseña, envío de códigos y endpoints caros. Tope máximo de tamaño de página y de profundidad de consulta.

Si el objeto recibido se vuelca sobre la entidad, el atacante añade campos que tú nunca pusiste en el formulario —rol, saldo, verificado, empresaId— y el ORM los guarda encantado. Se llama asignación masiva y es silenciosa.

Selecciona explícitamente los campos actualizables por endpoint y por rol, desde un objeto validado con esquema. Nada de esparcir el cuerpo. Marca en el modelo qué atributos jamás son escribibles desde la capa HTTP.

El filtrado del frontend es cosmético: la respuesta viaja entera y se lee en las herramientas de desarrollo o con curl. Así se filtran hashes de contraseña, correos, teléfonos, notas internas y campos de otros módulos.

Define un objeto de salida explícito por endpoint con los campos que de verdad se publican, y adapta ese conjunto al rol de quien pregunta. Marca el esquema de respuesta en la API para que lo no declarado no salga.

Sin validación entra cualquier cosa: tipos inesperados que rompen la lógica, cadenas gigantes que agotan la memoria, objetos anidados que bloquean el bucle de eventos y campos extra que acaban en la base de datos.

Valida en el borde con un esquema estricto (zod o el JSON Schema de Fastify): tipos, formatos, longitudes, rangos, enumeraciones y rechazo de propiedades desconocidas. Fija un límite de tamaño de cuerpo y de profundidad, y valida también rutas, query y cabeceras.

Si el proceso corre como root, cualquier ejecución de código que consigan es root dentro del contenedor, y desde ahí escapar al anfitrión es mucho más fácil. También permite reescribir la propia aplicación en caliente.

Usuario sin privilegios en la imagen, sistema de ficheros de solo lectura salvo los directorios que de verdad se escriben, capacidades del kernel recortadas, sin modo privilegiado y sin montar el socket de Docker. Imagen base mínima y actualizada.

Postgres, Redis, MongoDB y Elasticsearch abiertos al mundo se encuentran con un escaneo rutinario, y muchos vienen sin autenticación por defecto. Es el origen habitual de las fugas masivas y del ransomware de bases de datos.

Red privada y grupos de seguridad que solo permitan el tráfico desde los servicios que lo necesitan; acceso administrativo por túnel o bastión; autenticación obligatoria, TLS y credenciales distintas por servicio con el mínimo privilegio.

Cuando aparezca el incidente, la primera pregunta es qué cambió y desde cuándo; sin versión trazable no hay respuesta y el parche urgente se aplica a ciegas. Sin reversión, un despliegue malo se convierte en una caída larga.

Artefactos inmutables etiquetados con el hash del commit, despliegue automatizado y reproducible, reversión probada de verdad, y comprobaciones de salud y migraciones compatibles hacia atrás. La versión desplegada tiene que poder consultarse en cualquier momento.