Volver a recursos
Checklist

Checklist de seguridad para APIs REST

28 puntos de seguridad que toda API que expone datos empresariales debería cumplir. Basado en OWASP API Security Top 10 y experiencia en proyectos de salud y fintech.

Por qué importa la seguridad de las APIs

Las APIs son la superficie de ataque más grande de cualquier aplicación moderna. El 91% de las organizaciones tuvieron un incidente de seguridad relacionado con APIs en 2023 (Salt Security API Security Report). En sectores como salud o fintech, una API mal asegurada puede suponer multas RGPD, pérdida de datos de pacientes o fraude financiero.

Este checklist está basado en el OWASP API Security Top 10 y en los patrones de vulnerabilidad que encontramos con más frecuencia en proyectos de software empresarial.


1. Autenticación y autorización

  • Cada endpoint requiere autenticación a menos que sea explícitamente público y se haya justificado por qué.
  • Se usa OAuth 2.0 / OpenID Connect o JWT con firma correcta. No se usan cookies de sesión en APIs consumidas por terceros.
  • Los tokens JWT tienen tiempo de expiración corto (máximo 1 hora para access tokens) y se usan refresh tokens para renovación.
  • Los tokens se validan en el servidor: firma, expiración, issuer y audience. No solo se decodifican.
  • Se implementa autorización a nivel de objeto (BOLA / IDOR): un usuario no puede acceder a recursos de otro usuario aunque cambie el ID en la URL. Ejemplo: /api/pedidos/12345 solo lo ve el dueño del pedido 12345.
  • Se implementa autorización a nivel de función: los roles están definidos y cada endpoint verifica que el usuario tiene el rol necesario.
  • Las claves de API (si se usan) se rotan periódicamente y se pueden revocar individualmente.

2. Exposición de datos

  • Los endpoints solo devuelven los campos necesarios. No se hace SELECT * y se expone todo el objeto al cliente.
  • Los campos sensibles (contraseñas, tokens, datos bancarios, datos de salud) nunca aparecen en respuestas de API, aunque sea en campos "ocultos".
  • Los mensajes de error no revelan información interna: rutas de ficheros, queries SQL, stack traces, versiones de librerías.
  • Los endpoints de listado tienen paginación obligatoria con límite máximo razonable (ej. 100 registros por página).

3. Validación de entrada

  • Todos los parámetros de entrada se validan en el servidor: tipo, formato, longitud máxima, caracteres permitidos.
  • La validación ocurre en el servidor independientemente de la validación en el cliente.
  • Los campos de texto se sanean para prevenir inyección SQL, XSS y inyección de comandos.
  • Las subidas de ficheros validan el tipo real del fichero (no solo la extensión) y tienen límite de tamaño.
  • Los endpoints que reciben JSON tienen un límite de tamaño del body (ej. 1MB) para prevenir ataques de denegación de servicio.

4. Rate limiting y abuso

  • Existe rate limiting por IP y/o por usuario en todos los endpoints, especialmente en los de autenticación.
  • Los endpoints de login tienen bloqueo temporal tras N intentos fallidos consecutivos (ej. 5 intentos → bloqueo 15 minutos).
  • Existe protección contra scraping masivo: si alguien pagina todos los recursos a alta velocidad, se detecta y bloquea.
  • Los endpoints de reset de contraseña y OTP tienen rate limiting estricto.

5. Transporte y cabeceras

  • La API solo acepta conexiones HTTPS. Las peticiones HTTP redirigen a HTTPS o se rechazan.
  • El certificado TLS es válido, no ha expirado y usa TLS 1.2 como mínimo (preferible 1.3).
  • Las cabeceras de respuesta incluyen:
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: DENY
    • Strict-Transport-Security: max-age=31536000
  • Los endpoints CORS tienen una lista blanca de orígenes permitidos. No se usa Access-Control-Allow-Origin: * en APIs con datos sensibles.

6. Inventario y gobierno

  • Existe un inventario actualizado de todos los endpoints de la API: URL, método, autenticación requerida, datos que maneja.
  • Las APIs de terceros integradas están documentadas: qué datos envías, qué recibes, bajo qué condiciones de privacidad.
  • Los endpoints deprecados o no utilizados están desactivados. Las APIs "zombie" son una fuente frecuente de vulnerabilidades.
  • Existe un proceso para gestionar vulnerabilidades: cómo se reportan, quién las atiende, en cuánto tiempo se parchean.

Herramientas recomendadas

FinalidadHerramienta gratuitaHerramienta de pago
Escaneo de vulnerabilidadesOWASP ZAPBurp Suite Pro
Auditoría de dependenciasnpm audit, trivySnyk, Dependabot
Pruebas de carga / DoSk6, LocustArtillery Pro
Gestión de secretosHashiCorp Vault (open source)AWS Secrets Manager, GCP Secret Manager
Análisis estático (SAST)Semgrep (community)SonarQube, Checkmarx

Referencias

¿Necesitas ayuda para aplicarlo en tu empresa?

Nuestro equipo puede acompañarte en la implementación de las mejores prácticas técnicas para tu proyecto.

Hablar con nuestro equipo