AnestedAnested
Blog
Engineering·7 min read

Seguridad de APIs Node.js: nuestra lista de control

Cada API Express que entregamos pasa la misma revisión de seguridad. Aquí está la lista real — del rate limiting y el manejo de JWT a los errores de inyección SQL que aún vemos en revisiones de código.

Por Anested Engineering

Cada API Express que sale de nuestro taller pasa la misma revisión de seguridad antes de tocar producción. La lista es lo bastante corta como para seguirla de verdad, y ese es el punto — un documento de seguridad de cuarenta puntos que nadie lee no protege nada.

Primero, las fronteras de autenticación. Los tokens se verifican en cada ruta protegida mediante middleware, nunca dentro de handlers individuales donde un refactor puede eliminar silenciosamente la comprobación. Los JWT tienen expiraciones cortas, y cualquier operación privilegiada relee el rol del usuario desde la base de datos en lugar de confiar en claims horneadas en un token que podría tener un día de antigüedad.

Segundo, rate limiting en cada superficie pública — y límites distintos para superficies distintas. Los endpoints de login reciben un puñado de intentos por ventana, porque el credential stuffing es un negocio de volumen. Los endpoints de formularios públicos reciben margen suficiente para usuarios reales y nada más. El limitador es middleware aburrido, y aburrido es lo que quieres frente a un ataque de fuerza bruta.

Tercero, consultas parametrizadas sin excepciones. Cada sentencia SQL de nuestro código usa placeholders; interpolar cadenas en una consulta es rechazo automático en revisión, incluso cuando el valor 'no puede de ninguna manera' venir de un usuario. Los valores que genuinamente deben alterar la estructura de la consulta — una columna de ordenación, un intervalo — salen de una lista blanca fija en el código, nunca de la petición.

Cuarto, validar en la frontera y escapar en la salida. Los cuerpos de las peticiones se comprueban en forma y cordura en cuanto llegan. Todo lo que después vaya a un correo, una línea de log o una plantilla HTML se escapa para ese destino. El cross-site scripting es casi siempre un problema de salida disfrazado de problema de entrada.

Por último, los esenciales silenciosos: cabeceras de seguridad vía Helmet, CORS restringido a orígenes conocidos, secretos en variables de entorno que nunca llegan al repositorio, y respuestas de error que dicen 'algo salió mal' al cliente mientras el stack trace real va a los logs. Los atacantes leen los mensajes de error con más atención que la mayoría de los desarrolladores.

Nada de esto es exótico. Esa es la lección que ofreceríamos a cualquier equipo: a las APIs que sufren brechas rara vez les faltan defensas avanzadas — les faltan los fundamentos, aplicados con constancia. Una lista que realmente ejecutas vale más que un diagrama de arquitectura que admiras.

¿Necesitas ayuda con algo de este artículo?

Nuestros ingenieros responden directamente — hosting, bases de datos, código o cualquier tema de este artículo.