Seguridad de las API: autenticación, autorización y exploits comunes

Por qué las API son un objetivo prioritario

Las API se han convertido en el patrón arquitectónico dominante de las aplicaciones modernas: los clientes móviles, las aplicaciones de página única, los microservicios y las integraciones de terceros se comunican a través de ellas. Esta ubicuidad las convierte en un objetivo atractivo: un único endpoint de API vulnerable puede exponer los datos de millones de usuarios, eludir la autenticación o conceder acceso administrativo no autorizado. OWASP mantiene una lista dedicada, el API Security Top 10, precisamente porque las vulnerabilidades de las aplicaciones web no captan por completo los riesgos específicos de las API.

Autenticación: demostrar la identidad en la capa de la API

Claves de API

Las claves de API son el mecanismo de autenticación más simple: un secreto estático compartido con el cliente. Son apropiadas para la comunicación servidor a servidor, donde el cliente es un sistema backend de confianza. Prácticas críticas:

• Trata las claves de API como contraseñas: nunca las registres en logs, nunca las incluyas en las URL (usa el encabezado Authorization), nunca las subas al control de versiones
• Emite claves por cliente para poder revocar claves individuales sin afectar a las demás
• Establece fechas de caducidad y rota las claves con regularidad
• Limita el alcance de las claves a los permisos mínimos necesarios

Autenticación basada en JWT

Los JWT (JSON Web Tokens) codifican reclamaciones que el servidor puede verificar sin una consulta a la base de datos, lo que los hace populares para las API sin estado. Un JWT consta de un encabezado, una carga útil y una firma: header.payload.signature, cada uno codificado en Base64URL.

Pasos de validación críticos:

1. Verify the signature using the correct algorithm (reject alg:none)
2. Check iss (issuer) matches your expected authority
3. Check aud (audience) is your API
4. Check exp (expiration) — reject expired tokens
5. Check nbf (not before) if present

Nunca confíes en el campo alg del encabezado del token para determinar la lógica de validación: fija siempre el algoritmo esperado en el lado del servidor.

Alcances de OAuth para la autorización

Para las API orientadas al usuario, utiliza OAuth 2.0 con alcances de grano fino: read:profile, write:orders, admin:billing. Cada endpoint de la API debe validar que el token presentado contiene el alcance requerido. Un token válido no implica acceso a todo.

OWASP API Security Top 10: los riesgos críticos

Autorización rota a nivel de objeto (BOLA)

BOLA —también llamada IDOR (referencia directa e insegura a objetos)— es sistemáticamente el riesgo de seguridad de API n.º 1. Ocurre cuando un endpoint de API acepta un ID de objeto en la solicitud pero no verifica que el usuario que la realiza sea realmente propietario de ese objeto:

GET /api/orders/12345  →  returns order 12345
GET /api/orders/12346  →  returns another user's order (BOLA!)

Defensa: para cada endpoint de acceso a objetos, verifica que el usuario autenticado tenga una relación con el objeto solicitado. Nunca te bases únicamente en el ID del objeto.

Autorización rota a nivel de función

Las funciones administrativas se exponen en URL predecibles, pero se basan en ocultarlas del lado del cliente en lugar de aplicarlas del lado del servidor:

POST /api/admin/deleteUser  →  accessible to regular users

Defensa: aplica un control de acceso basado en roles en cada endpoint, del lado del servidor. Prueba con regularidad todos los endpoints, aparezcan o no en la interfaz para tu rol.

Autorización rota a nivel de propiedad de objeto

Una API puede restringir correctamente a qué objetos puedes acceder, pero exponer o permitir la modificación de campos internos dentro de esos objetos:

PUT /api/users/me  {"role": "admin"}  →  mass assignment vulnerability

Defensa: usa listas de permitidos explícitas para los campos que se pueden leer o escribir por endpoint. Nunca pases los objetos del cuerpo de la solicitud directamente a los métodos del ORM (por ejemplo, update(params[:user]) de Rails sin permit).

Consumo de recursos sin restricciones

Sin limitación de tasa, un solo cliente puede agotar el cómputo, las conexiones a la base de datos o la cuota de servicios de terceros de tu API:

• Implementa limitación de tasa por usuario, por IP y por clave de API
• Devuelve 429 Too Many Requests con encabezados Retry-After
• Limita el tamaño del cuerpo de la solicitud para evitar la denegación de servicio mediante cargas útiles sobredimensionadas
• Pagina y limita los resultados: nunca devuelvas colecciones sin límite
• Aplica límites de profundidad de consulta para las API de GraphQL

Utiliza herramientas como el módulo limit_req de nginx, la limitación de AWS API Gateway o pasarelas de API dedicadas (Kong, Envoy) para la limitación de tasa.

Configuración de seguridad incorrecta

Las configuraciones incorrectas de API más comunes incluyen:

• CORS establecido en Access-Control-Allow-Origin: * en endpoints autenticados
• Mensajes de error detallados que exponen trazas de pila, consultas a la base de datos o rutas internas
• Métodos HTTP no restringidos (PUT/DELETE habilitados donde solo debería estar GET/POST)
• Falta de aplicación de HTTPS
• Documentación de Swagger/OpenAPI expuesta públicamente en producción

Fallos sensibles en la lógica de negocio

No todas las vulnerabilidades de API son técnicas: algunas explotan la propia lógica de negocio:

• Aplicar un código de cupón de descuento varias veces
• Transferir una cantidad negativa para añadir fondos
• Omitir pasos de pago obligatorios llamando directamente a un endpoint de API posterior

Estos requieren conocimiento del dominio para encontrarlos y no pueden ser detectados solo por escáneres automáticos. Incluye pruebas de lógica de negocio en tus revisiones de seguridad de las API.

Refuerzo práctico de la seguridad de las API

• Usa HTTPS en todas partes y redirige HTTP a HTTPS; establece el encabezado Strict-Transport-Security
• Valida toda la entrada: rechaza campos inesperados, valida tipos, rangos y formatos
• Devuelve datos mínimos: no incluyas ID internos, marcas de tiempo del lado del servidor ni metadatos del sistema en las respuestas
• Registra todas las llamadas a la API con suficiente contexto (ID de usuario, endpoint, código de respuesta, duración) para el análisis forense
• Usa una pasarela de API para centralizar la autenticación, la limitación de tasa, el registro y la detección de amenazas
• Prueba con OWASP ZAP o Burp Suite contra tu propia documentación de API: cada endpoint de tu especificación OpenAPI debe probarse frente a la elusión de autenticación y BOLA