Las API (interfaces de programación de aplicaciones) son el tejido conectivo del software actual: cada pago con tarjeta, cada inicio de sesión con una cuenta externa y cada integración entre sistemas pasa por una. Esa centralidad las convierte también en el principal vector de ataque. Según el OWASP API Security Top 10, las vulnerabilidades más explotadas no son fallos exóticos, sino errores de diseño en la autorización y la validación. Desarrollar una API segura no es añadir una capa al final, sino tomar decisiones correctas de arquitectura, autenticación y control de acceso desde el primer endpoint.
REST y GraphQL: cuándo conviene cada uno
La elección del estilo arquitectónico condiciona el modelo de seguridad. REST organiza la API en recursos identificados por URL y métodos HTTP (GET, POST, PUT, DELETE), con una superficie de ataque predecible: cada endpoint protege un recurso. GraphQL expone un único endpoint sobre el que el cliente compone consultas flexibles, lo que reduce el sobreenvío de datos pero introduce riesgos propios, como consultas anidadas que pueden provocar denegación de servicio si no se limita su profundidad y complejidad.
| Aspecto | REST | GraphQL |
|---|---|---|
| Endpoints | Múltiples, uno por recurso | Uno solo |
| Obtención de datos | Riesgo de over/under-fetching | El cliente pide exactamente lo que necesita |
| Caché HTTP | Nativa y sencilla | Compleja (todo es POST) |
| Riesgo característico | Endpoints expuestos sin autorizar | Consultas profundas y costosas |
Autenticación frente a autorización: no son lo mismo
Confundir ambos conceptos es la raíz de muchas brechas. La autenticación responde a «¿quién eres?» y la autorización a «¿qué puedes hacer?». El estándar de referencia para delegar acceso es OAuth 2.0 (RFC 6749), que permite que una aplicación acceda a recursos en nombre del usuario sin manejar su contraseña, mediante tokens de acceso. Sobre OAuth 2.0 se apoya OpenID Connect, que añade la capa de identidad (saber quién es el usuario, no solo qué puede hacer).
Para el flujo de aplicaciones de servidor se usa el Authorization Code Flow, y para aplicaciones públicas (SPA y móvil) se le añade PKCE (Proof Key for Code Exchange, RFC 7636), que evita la interceptación del código de autorización. Los tokens suelen materializarse como JWT (JSON Web Tokens): tokens firmados que el servidor puede validar sin consultar una base de datos. Conviene mantener los access tokens de vida corta y delegar la renovación en refresh tokens de vida más larga y revocables.
BOLA: la vulnerabilidad número uno
El primer puesto del OWASP API Security Top 10 lo ocupa BOLA (Broken Object Level Authorization). Ocurre cuando un endpoint comprueba que el usuario está autenticado, pero no que el objeto solicitado le pertenece. El ejemplo clásico: GET /api/facturas/1043 devuelve la factura correctamente al usuario propietario, pero si otro usuario autenticado cambia el identificador a 1044 y recibe la factura de un tercero, la API tiene una vulnerabilidad BOLA grave. La defensa es verificar siempre, en cada operación, que el sujeto autenticado tiene permiso sobre el objeto concreto, nunca confiar en que un identificador difícil de adivinar baste como protección.
Rate limiting y protección frente a abuso
Sin límites de tasa, una API queda expuesta a fuerza bruta de credenciales, scraping masivo y denegación de servicio. El rate limiting restringe el número de peticiones por cliente en una ventana temporal. Los algoritmos más usados son el token bucket (permite ráfagas controladas), el leaky bucket (suaviza el caudal) y la ventana deslizante (sliding window). Es buena práctica comunicar los límites con cabeceras estándar como RateLimit-Limit y RateLimit-Remaining, y responder con el código 429 Too Many Requests acompañado de la cabecera Retry-After cuando se supera el umbral.
Validación de entrada y prevención de inyecciones
Toda entrada del cliente es hostil hasta demostrar lo contrario. La validación debe aplicar el principio de lista blanca: definir explícitamente qué se acepta (tipo, longitud, formato, rango) y rechazar el resto, en lugar de intentar filtrar lo malo. Las consultas a base de datos deben usar siempre sentencias parametrizadas para neutralizar la inyección SQL, y la salida debe codificarse según el contexto para prevenir XSS. Validar un esquema de petición con herramientas como JSON Schema o la especificación OpenAPI permite rechazar peticiones malformadas antes de que lleguen a la lógica de negocio.
El API gateway: un punto único de control
A medida que crece el número de servicios, gestionar la seguridad endpoint por endpoint se vuelve inmanejable. El API gateway resuelve este problema al situarse delante de los servicios como punto único de entrada. Centraliza tareas transversales que de otro modo habría que reimplementar en cada servicio: terminación TLS, validación de tokens, aplicación de rate limiting y cuotas, enrutamiento, transformación de peticiones y registro de tráfico. Concentrar estas funciones en el gateway evita la duplicación de lógica de seguridad y, sobre todo, evita las incoherencias: un único lugar donde se decide quién puede llamar y con qué frecuencia.
El gateway también es el lugar natural para implantar el modelo de confianza cero en las comunicaciones internas. En arquitecturas de microservicios modernas, los servicios se autentican entre sí mediante mTLS (TLS mutuo), de forma que cada llamada interna verifica tanto la identidad del cliente como la del servidor. Así, comprometer un único servicio no concede acceso libre al resto del sistema, porque cada salto sigue exigiendo credenciales válidas.
Seguridad de los webhooks
Los webhooks invierten el flujo habitual: en lugar de que el cliente consulte la API, es el servidor quien notifica al cliente cuando ocurre un evento. Esto plantea un riesgo distinto, porque el receptor expone un endpoint público que cualquiera podría invocar. La defensa estándar es la verificación de firma: el emisor calcula un HMAC del cuerpo del mensaje con un secreto compartido y lo envía en una cabecera; el receptor recalcula la firma y la compara antes de procesar nada. Conviene además incluir una marca de tiempo en la firma para evitar ataques de repetición (replay) y rechazar mensajes antiguos.
Pasos para diseñar una API segura
- Forzar HTTPS en todos los endpoints; nunca aceptar tráfico en claro.
- Autenticar con OAuth 2.0 / OpenID Connect y tokens de vida corta, evitando claves de API estáticas embebidas en clientes.
- Autorizar a nivel de objeto y de función en cada petición, asumiendo el modelo de mínimo privilegio.
- Validar todas las entradas contra un esquema y parametrizar las consultas.
- Aplicar rate limiting y cuotas por cliente, usuario e IP.
- Versionar la API (
/v1/,/v2/) para evolucionar sin romper integraciones. - Registrar y monitorizar accesos y anomalías, sin volcar datos sensibles en los logs.
- Documentar con OpenAPI y mantener la documentación sincronizada con el código.
Errores comunes
El primero es la autorización rota a nivel de objeto (BOLA) ya descrita. El segundo es la exposición excesiva de datos: devolver el objeto completo de la base de datos y confiar en que el cliente solo muestre los campos relevantes, cuando el atacante inspecciona la respuesta cruda. El tercero es no limitar recursos, dejando la API abierta a paginaciones masivas o consultas GraphQL ilimitadas. El cuarto es la mala gestión de secretos: claves y tokens en el código fuente o en repositorios. El quinto, y muy frecuente, es la API shadow o zombie: endpoints de versiones antiguas que siguen activos sin mantenimiento ni protección.
Preguntas frecuentes
¿Qué es mejor, una API key o OAuth 2.0? Las API keys identifican una aplicación pero no a un usuario y son difíciles de rotar y revocar. OAuth 2.0 ofrece tokens de vida corta, ámbitos de permiso (scopes) y revocación. Para acceso de usuario, OAuth 2.0 con OpenID Connect es el estándar recomendado; las API keys quedan para integraciones servidor a servidor de bajo riesgo.
¿GraphQL es menos seguro que REST? No es menos seguro por naturaleza, pero traslada el riesgo: en REST se vigila cada endpoint; en GraphQL hay que limitar la profundidad y la complejidad de las consultas, aplicar listas blancas de operaciones y deshabilitar la introspección en producción.
¿Dónde almaceno los tokens en una aplicación web? Para SPA, evitar localStorage por su exposición a XSS; preferir cookies HttpOnly, Secure y SameSite, complementadas con protección CSRF. Para móviles, usar el almacén seguro del sistema operativo.
¿Cada cuánto debo rotar las credenciales? Los access tokens deben caducar en minutos u horas; los secretos de cliente y las API keys deben rotarse de forma periódica y, obligatoriamente, ante cualquier sospecha de filtración, con un proceso de rotación automatizado y sin interrupción.
Conclusión
La seguridad de una API se gana o se pierde en el diseño de la autorización, no en la potencia del cifrado. El dato más revelador del OWASP API Security Top 10 es que los fallos dominantes (BOLA, autorización rota a nivel de función, exposición excesiva de datos) son errores de lógica de negocio que ninguna herramienta automática detecta por completo: dependen de comprobar, en cada operación, que este usuario puede hacer esto sobre este objeto. Una API moderna combina OAuth 2.0 con PKCE, tokens de vida corta, validación estricta por esquema, rate limiting y observabilidad, todo versionado y documentado con OpenAPI. En Summum diseñamos e integramos APIs aplicando este modelo desde el primer endpoint, de manera que abrir una integración a un tercero no signifique abrir una puerta al resto del sistema.