Saltar al contenido principal

Seguridad en APIs REST

🎯 Objetivo​

Regla​

7.1: Se deben comprender y aplicar los principios y prácticas fundamentales para asegurar las APIs REST en múltiples capas. 7.2: La protección de datos, la autenticación y autorización robustas, y la mitigación de vulnerabilidades comunes son obligatorias.

📖 Concepto y Definición​

Regla​

7.3: La seguridad en APIs REST es un requisito fundamental y abarca los siguientes pilares obligatorios:

  • Autenticación (¿Quién eres?): Proceso de verificar la identidad del cliente. Debe implementarse.
  • Autorización (¿Qué puedes hacer?): Proceso de determinar los permisos de un cliente autenticado sobre un recurso/acción. Debe implementarse.
  • Confidencialidad de Datos: Asegurar la protección de datos en tránsito. Debe lograrse mediante HTTPS.
  • Integridad de Datos: Asegurar que los datos no sean alterados en tránsito (cubierto por HTTPS).
  • Protección contra Amenazas: Mitigar activamente vulnerabilidades comunes.

Mecanismos Obligatorios de Autenticación:​

Regla​

7.4: El mecanismo de autenticación predeterminado y obligatorio para las APIs REST que requieren identificar al usuario final o asegurar interacciones servidor-a-servidor de forma robusta es mediante Tokens Bearer (específicamente JWTs firmados digitalmente o Tokens de Acceso OAuth 2.0).

  • El cliente debe enviar el token en el encabezado Authorization: Bearer <token>.
  • El servidor debe validar rigurosamente el token (firma, expiración, emisor, audiencia). 7.5: La Autenticación Básica (Basic Auth) (Authorization: Basic <base64(user:pass)>) está prohibida para APIs expuestas externamente o que manejen datos sensibles, debido a su inseguridad inherente si HTTPS falla o es mal configurado. 7.6: Las Claves API (API Keys) simples (ej. en encabezado X-API-Key) solo pueden usarse para identificar aplicaciones cliente en casos de uso de bajo riesgo donde no se necesita identificar al usuario final, y siempre sobre HTTPS. No deben usarse para autenticación de usuarios.

🤔 ¿Por qué es Importante? / Beneficios Clave (Contexto)​

  • Protección de Datos: Evita acceso no autorizado.
  • Control de Acceso: Asegura permisos correctos.
  • Prevención de Abuso: Mitiga uso malintencionado.
  • Cumplimiento: Cumple regulaciones (GDPR, HIPAA).
  • Confianza del Usuario: Genera confianza.
  • Disponibilidad: Protege contra DoS.

✅ Buenas Prácticas y Recomendaciones Clave​

Autenticación:​

Regla​

7.7: HTTPS (TLS/SSL) es obligatorio para toda la comunicación de la API. No se debe permitir comunicación HTTP. 7.8: Se refuerza la Norma 7.4: Se debe usar Tokens Bearer (JWT/OAuth 2.0) como método principal. 7.9: Las contraseñas de usuario deben almacenarse siempre usando funciones hash robustas y con salt (ej. bcrypt, Argon2). Está prohibido almacenar contraseñas en texto plano o con hashes débiles (MD5, SHA1). 7.10: Los tokens de acceso (JWTs) deben tener tiempos de expiración cortos (ej. minutos u horas, no días/semanas). Se debe implementar un mecanismo seguro de refresco de tokens (ej. refresh tokens en OAuth 2.0) para mejorar la experiencia del usuario sin comprometer la seguridad. 7.11: La validación de JWTs debe incluir la verificación de: firma, fecha de expiración (exp), emisor (iss), y audiencia (aud). 7.12: Se debe implementar un mecanismo para la revocación de tokens (ej. listas negras, JTI) para casos como cierre de sesión o compromiso de cuenta.

Autorización:​

Regla​

7.13: Se debe aplicar el Principio de Mínimo Privilegio: otorgar solo los permisos estrictamente necesarios. 7.14: Se debe implementar un sistema de control de acceso basado en roles (RBAC) o atributos (ABAC) para gestionar permisos de forma granular y centralizada. 7.15: Se deben realizar chequeos de autorización explícitos en cada endpoint protegido, verificando no solo la autenticación sino también los permisos específicos para la acción y el recurso solicitado. 7.16: Los permisos deben ser específicos. Están prohibidos permisos excesivamente genéricos.

Protección General de la API:​

Regla​

7.17: Se debe realizar una validación rigurosa de todas las entradas (parámetros de URI, query, encabezados, cuerpo) para prevenir ataques de inyección (SQLi, NoSQLi, command injection, XSS si se refleja contenido). Se recomienda usar DTOs con bibliotecas de validación. 7.18: La sanitización de salidas es obligatoria si la API devuelve contenido que pueda ser interpretado por un navegador (HTML). Para JSON, se debe asegurar que el Content-Type sea application/json y que el contenido esté correctamente codificado para prevenir XSS si se inserta en DOM. 7.19: Se debe implementar Rate Limiting y Throttling para prevenir abuso y ataques DoS. Los límites deben ser razonables y documentados. 7.20: Se deben configurar encabezados de seguridad HTTP relevantes en las respuestas, como mínimo: Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options: DENY (o SAMEORIGIN), y Content-Security-Policy (CSP) con directivas restrictivas si la API puede ser llamada desde navegadores. 7.21: El manejo de errores debe ser seguro (Norma 4.7): No se debe exponer información sensible (stack traces, mensajes detallados de DB) al cliente. Se deben loguear los detalles internamente. 7.22: Si se usan cookies para autenticación (generalmente no recomendado para APIs REST puras, preferir Bearer tokens), la protección CSRF es obligatoria. 7.23: Las dependencias (bibliotecas, frameworks), servidores y sistemas operativos deben mantenerse actualizados y parcheados regularmente. 7.24: Se deben realizar auditorías de seguridad y/o pruebas de penetración periódicas. 7.25: No se deben exponer IDs internos secuenciales o fácilmente adivinables si esto puede llevar a ataques IDOR (Insecure Direct Object References). Se debe preferir el uso de UUIDs o implementar chequeos de autorización estrictos que validen la propiedad del recurso.

Don'ts (Prohibido):

  • 7.26: No se debe usar HTTP.
  • 7.27: No se deben enviar credenciales (claves, tokens, contraseñas) en parámetros de URI.
  • 7.28: No se deben hardcodear secretos o claves en código fuente (cliente o servidor).
  • 7.29: No se debe implementar criptografía propia. Se deben usar bibliotecas estándar y probadas.
  • 7.30: No se debe confiar ciegamente en ningún dato proveniente del cliente.

💡 Ejemplos Prácticos (Ilustrativos)​

Ejemplo 1: Autenticación con Token JWT (Norma 7.4, 7.10, 7.11)​

  • Solicitud Cliente (Login): (Ver sección de Autenticación específica si existe, o endpoint dedicado)
  • Respuesta Servidor (Login Exitoso): 
    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store // No cachear tokens
    Pragma: no-cache

    {
      "accessToken": "<JWT_FIRMADO_Y_CON_EXPIRACION_CORTA>",
      "tokenType": "Bearer",
      "expiresIn": 3600, // Segundos hasta expiración
      "refreshToken": "<REFRESH_TOKEN_SEGURO_SI_APLICA>"
    }
  • Solicitud Cliente (Recurso Protegido): 
    GET /profile HTTP/1.1
    Host: api.example.com
    Authorization: Bearer <JWT_FIRMADO_Y_CON_EXPIRACION_CORTA>
    Accept: application/json
    El servidor debe validar el token antes de procesar.

Ejemplo 2: Rate Limiting (Norma 7.19)​

Si un cliente excede el límite:

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json // O application/json consistente con errores
Retry-After: 60 // Segundos a esperar (opcional pero recomendado)

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED", // Código de error consistente
    "message": "Has excedido el límite de solicitudes. Intenta de nuevo más tarde."
    // ... otros campos del formato de error estándar
  }
}

Ejemplo 3: Encabezados de Seguridad (Norma 7.20)​

Respuesta del servidor debe incluir encabezados como:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'; // Ejemplo restrictivo

🛠️ Herramientas y Consideraciones Adicionales (Contexto)​

  • OWASP API Security Top 10: Debe ser una referencia obligatoria.
  • OAuth 2.0 / OIDC: Son los estándares recomendados para delegación de autorización e identidad.
  • WAF: Puede ser una capa adicional de defensa.
  • Gestores de Secretos: Se recomienda su uso para gestionar credenciales de forma segura.
  • Security Scanners: Herramientas DAST/SAST deben incorporarse al ciclo de desarrollo.