La certificación JSNSD evalúa tu capacidad para construir APIs REST seguras en Node.js, y el dominio de Security es la primera prueba que enfrentas. Aquí te muestro cómo resolver un ejercicio típico paso a paso, qué herramientas usar y por qué dominar el ecosistema de tu framework favorito marca la diferencia entre aprobar o quedarte corto en tiempo.

¿Qué evalúa el dominio Security de JSNSD?

Este dominio representa el 30% de la prueba y se compone de dos tareas: el task 1.1 y el task 1.2. Ambas miden tu conocimiento sobre prácticas de seguridad en APIs REST construidas con Node.js [1:00].

Los ejercicios son extensos, así que vas a escribir bastante código bajo presión de tiempo. La clave está en llegar preparado con tres recursos de cabecera:

• El artículo de Snyk sobre prácticas comunes de seguridad en Node.js.
• El repositorio Awesome Security Node.js en GitHub.
• Un cheat sheet de seguridad para consulta rápida durante la prueba.

¿Cuántos ejercicios tiene el dominio Security? Solo dos: el task 1.1 y el task 1.2. Pero cada uno requiere una cantidad significativa de código y conocimiento profundo del framework elegido.

¿Por qué elegir un framework favorito antes de la prueba?

No se trata de saber un poco de todo, sino de dominar uno. En esta clase trabajamos con Fastify porque su ecosistema de plugins resuelve problemas de seguridad complejos en pocas líneas. Tener un framework de cabecera te permite ir a la documentación con confianza y ahorrar minutos críticos.

¿Cómo resolver el task 1.1 paso a paso?

El ejercicio entrega un archivo answer.js con dos elementos: una variable de entorno port y una función login(user, password) que devuelve true si el usuario es node y la contraseña es developer [3:30].

A partir de ahí, las instrucciones piden cuatro cosas concretas que conviene resolver en orden:

1. Construir un servidor web que escuche en la variable de entorno port.
2. Crear un endpoint /login que acepte solo método POST con username y password en JSON.
3. Validar credenciales con la función login y responder 200 o 401 según el caso.
4. Bloquear con código 429 a cualquier IP que haga más de tres requests en 15 segundos.

¿Cómo levantar el servidor con Fastify?

Después de instalar Fastify con npm install fastify, se importa el módulo y se crea la instancia con logger: true para tener visibilidad de las peticiones [5:30]. Luego se configura el listen tomando el puerto desde process.env.port con un fallback a 3000 por si no llega la variable de entorno.

Un detalle importante: como vamos a usar top-level await más adelante, el archivo debe renombrarse de .js a .mjs para convertirlo en módulo de ECMAScript. Si dejas la extensión .js, el código falla porque CommonJS no admite await en el nivel superior.

¿Cómo crear el endpoint POST /login?

Con fastify.post('/login', ...) se define la ruta. Dentro del handler se desestructuran username y password desde request.body, se invoca la función login y se responde según el resultado:

• Si la validación falla, se retorna reply.code(401).
• Si la validación pasa, se envía un objeto vacío con reply.send({}).

El ejercicio aclara que no hay que mandar información adicional, solo el status code correcto.

¿Cómo bloquear IPs con rate limiting en Fastify?

Aquí entra la parte específica de seguridad. Implementar un limitador de peticiones a mano tomaría demasiado tiempo, así que la jugada inteligente es usar @fastify/rate-limit, un plugin oficial del ecosistema que bloquea clientes según su dirección IP [10:30].

La instalación es directa con npm install @fastify/rate-limit. El registro se hace después de crear el servidor y antes de definir las rutas, configurando dos opciones:

• max: 3 para permitir solo tres peticiones.
• timeWindow: 15000 para definir la ventana en milisegundos (15 segundos).

¿Qué hace el plugin @fastify/rate-limit? Bloquea automáticamente a los clientes que superen un número de peticiones en una ventana de tiempo definida, identificándolos por su dirección IP. Es la forma más rápida de cumplir requisitos de rate limiting en la prueba.

¿Cómo personalizar el código de error 429?

El plugin permite definir un errorResponseBuilder que recibe request y context. Dentro de esa función se retorna un objeto con statusCode: 429 y un mensaje de error. Así, cuando alguien excede el límite, recibe exactamente el código que pide el ejercicio en lugar del mensaje genérico del plugin.

¿Cómo probar la solución antes de entregar?

En el entorno de la certificación tendrás Postman disponible; en la clase usamos Insomnia porque funciona casi igual. Antes de probar, configura el package.json con el script "start": "node answer.mjs" para que npm start levante el servidor [13:30].

Las pruebas que debes hacer son tres:

1. POST a /login con node y developer debe devolver 200.
2. POST con credenciales incorrectas debe devolver 401.
3. A partir del cuarto request en 15 segundos, la respuesta debe ser 429 con el mensaje too many requests.

Si los tres escenarios responden como se espera, el ejercicio queda resuelto. Ten presente que este nivel de complejidad es el estándar de JSNSD: solo seis ejercicios en toda la prueba, pero cada uno exige conocimiento avanzado del framework que elijas. ¿Cuál vas a usar tú para resolverlos? Cuéntame en los comentarios.