Seguridad: CORS, rate limiting y helmet

Estas tres medidas resuelven problemas distintos. CORS decide qué origen puede leer respuestas desde un navegador; el límite de solicitudes reduce abuso repetitivo; las cabeceras defensivas disminuyen información innecesaria del navegador. Ninguna sustituye autenticación ni validación.

Ejemplo resuelto

Si el cliente legítimo es https://biblioteca.test, una política explícita puede permitir solo ese origen. Un contador local de demostración con ventana de 60 segundos y máximo 3 solicitudes por IP permite las tres primeras y responde 429 a la cuarta. Las cabeceras defensivas deben añadirse globalmente, sin inventar una lista de orígenes comodín.

Pruébalo

1. Envía una solicitud con origen permitido y otra no permitido.

2. Repite cuatro veces una ruta limitada dentro de la misma ventana.

3. Registra código, origen y contador restante.

4. Comprueba que la ruta sigue validando el cuerpo.

Error frecuente: usar * junto con credenciales o pensar que CORS bloquea clientes no navegador. Corrígelo restringiendo orígenes y tratando CORS como política de lectura, no como control de identidad.

Comprueba tu resultado

Las tres primeras solicitudes reciben la respuesta normal y la cuarta 429. El origen permitido aparece en la respuesta; el no permitido no obtiene autorización CORS. Para una entrada inválida, reinicia la ventana de prueba y envía una primera solicitud: debe producir 400. Si agotaste el límite antes, un middleware limitador puede responder 429 antes de la validación; registra el orden configurado en lugar de prometer siempre 400.