Mejores prácticas de seguridad de API: autenticación, autorización y limitación de velocidad

Las API son el tejido conectivo de las plataformas comerciales modernas. Su ERP se comunica con su tienda de comercio electrónico a través de API. Su pasarela de pago procesa transacciones a través de API. Su aplicación móvil obtiene datos a través de API. Y los atacantes lo saben: Gartner predice que para 2026, las API serán el vector de ataque más frecuente para las aplicaciones web empresariales, superando a las interfaces web tradicionales.

El Top 10 de seguridad de API de OWASP revela que las vulnerabilidades de API más comunes no son días cero exóticos, sino fallas de autenticación fundamentales, autorización incumplida y exposición excesiva de datos. Se trata de defectos evitables que se derivan de una arquitectura de seguridad inadecuada y no de ataques sofisticados.

Conclusiones clave

• OAuth2 con PKCE es el estándar actual para la autenticación API; Las claves API por sí solas no son suficientes para los sistemas de producción
• La autorización a nivel de objeto rota (BOLA) es la vulnerabilidad de API número uno: cada punto final debe verificar la propiedad del recurso
• La limitación de velocidad es un control de seguridad, no solo una optimización del rendimiento: evita el relleno de credenciales, la enumeración y el DoS
• La validación de entrada en el límite de la API evita ataques de inyección, desbordamiento y lógica empresarial antes de que lleguen a su base de datos.

---

Autenticación: demostrar identidad

La autenticación responde a la pregunta "¿quién realiza esta solicitud?" Para las API, la respuesta debe ser verificable criptográficamente, resistente a ataques de repetición y escalable en sistemas distribuidos.

Comparación de métodos de autenticación

Mejores prácticas de OAuth2 y OIDC

OAuth2 con OpenID Connect (OIDC) es el estándar para la autenticación API en aplicaciones modernas. Prácticas clave de implementación:

Utilice el flujo del Código de autorización con PKCE para todos los tipos de clientes, incluidas aplicaciones de una sola página y aplicaciones móviles. El flujo implícito está en desuso debido a la exposición del token en el historial del navegador y los encabezados de referencia.

Tokens de acceso de corta duración. Los tokens de acceso deben caducar en 15 a 60 minutos. Utilice tokens de actualización (almacenados de forma segura, rotados según su uso) para obtener nuevos tokens de acceso sin volver a autenticarse.

Almacenamiento de tokens. Nunca almacene tokens en localStorage o sessionStorage (vulnerable a XSS). Utilice cookies HttpOnly con atributos Secure y SameSite. Para los SPA que deben usar tokens directamente, manténgalos solo en la memoria y acepte la compensación de la pérdida de sesión al actualizar la página.

Valide los tokens minuciosamente. Cada solicitud de API debe verificar la firma, el vencimiento, el emisor, la audiencia y el alcance del token. No se limite a decodificar el JWT y confiar en su contenido.

Vinculación de tokens. Cuando sea posible, vincule los tokens al cliente que los solicitó mediante encabezados DPoP (Demostración de prueba de posesión) para evitar el robo y la reproducción de tokens.

Consideraciones de seguridad de JWT

Los JWT son el formato de token más común para las API, pero conllevan riesgos específicos:

• Nunca utilice el algoritmo none. Valide siempre el encabezado alg con una lista blanca de algoritmos esperados.
• Prefiera algoritmos asimétricos (RS256, ES256) a los simétricos (HS256) para las API públicas. Las claves asimétricas permiten la verificación del token sin compartir la clave de firma.
• Incluir afirmaciones estándar: iss (emisor), aud (audiencia), exp (vencimiento), iat (emitido en), sub (asunto), jti (ID único para revocación).
• Mantenga las cargas útiles pequeñas. Los JWT no son una base de datos. Incluya solo las afirmaciones necesarias para las decisiones de autorización. Obtenga datos adicionales de los puntos finales de información del usuario cuando sea necesario.
• Implementar la revocación de tokens. Utilice tiempos de vencimiento cortos combinados con una lista de bloqueo de tokens (en Redis o similar) para la revocación inmediata cuando las cuentas estén comprometidas.

---

Autorización: hacer cumplir el control de acceso

La autenticación le indica quién realiza la solicitud. La autorización le indica lo que se les permite hacer. El Top 10 de API de OWASP enumera la autorización a nivel de objeto rota (BOLA) como la vulnerabilidad de API número uno porque es a la vez la más común y la más impactante.

RBAC frente a ABAC

Control de acceso basado en roles (RBAC) asigna permisos a roles y los usuarios se asignan a roles. Es simple de implementar y razonar.

Control de acceso basado en atributos (ABAC) evalúa las políticas en función de los atributos del usuario, el recurso, la acción y el entorno. Admite reglas más complejas pero es más difícil de auditar.

Para la mayoría de las plataformas comerciales, incluidos los sistemas ERP y de comercio electrónico, RBAC es suficiente cuando se combina con comprobaciones de propiedad de recursos. Considere ABAC cuando sus reglas de autorización dependan de factores contextuales como el tiempo, la ubicación, la clasificación de datos o jerarquías organizativas dinámicas.

Prevención de BOLA

La autorización a nivel de objeto rota ocurre cuando una API permite a los usuarios acceder o modificar recursos que pertenecen a otros usuarios mediante la manipulación de identificadores de recursos. Por ejemplo, cambiar /api/orders/12345 a /api/orders/12346 no debería revelar el pedido de otro usuario.

Normas de prevención:

1. Cada punto final debe verificar la propiedad de los recursos. Nunca confíe únicamente en la autenticación. Después de verificar la identidad del usuario, verifique que tenga acceso al recurso específico que se solicita.
2. Utilice referencias indirectas. En lugar de exponer ID de bases de datos secuenciales, utilice UUID o números de referencia específicos del usuario.
3. Aplicar en la capa de datos. Agregue filtros de propiedad (por ejemplo, WHERE organization_id = ?) a cada consulta de la base de datos, no solo a nivel del controlador. Este es el patrón multiinquilino utilizado en toda la arquitectura de la plataforma de ECOSIRE.
4. Pruebas automatizadas. Incluya pruebas de omisión de autorización en su proceso de CI/CD. Para cada punto final, pruebe que el usuario A no pueda acceder a los recursos del usuario B.

---

Limitación y estrangulamiento de velocidad

La limitación de velocidad es un control de seguridad que evita el abuso, no solo una optimización del rendimiento que evita la sobrecarga. Sin limitación de velocidad, los atacantes pueden realizar relleno de credenciales en miles de intentos por segundo, enumerar cuentas válidas, eliminar todo su catálogo de productos o agotar sus cuotas de API con proveedores ascendentes.

Estrategias de limitación de tasas

Limitación de velocidad por tipo de terminal

Diferentes puntos finales enfrentan diferentes perfiles de amenazas y requieren límites diferentes:

• Puntos finales de autenticación (inicio de sesión, intercambio de tokens): 5-10 solicitudes por minuto por IP. Los límites bajos evitan el relleno de credenciales y la fuerza bruta.
• Restablecimiento de contraseña/recuperación de cuenta: 3-5 solicitudes por hora por cuenta. Previene la enumeración y el abuso de cuentas.
• Puntos finales de lectura de datos: 100-1000 solicitudes por minuto por usuario. Evita raspaduras y permite un uso normal.
• Puntos finales de escritura de datos: 30-60 solicitudes por minuto por usuario. Previene el abuso automatizado y el spam.
• Puntos finales de búsqueda públicos: 20-60 solicitudes por minuto por IP. Previene el raspado competitivo.
• Receptores de webhook: valida firmas en lugar de limitar la velocidad, pero descarta las solicitudes que exceden el volumen esperado.

Implementación de límites de tarifas

Devuelva códigos de estado HTTP y encabezados adecuados para que los clientes puedan autorregularse:

• 429 Demasiadas solicitudes cuando se excede el límite
• Encabezado Reintentar después con el número de segundos hasta que se restablezca el límite
• Cabecera X-RateLimit-Limit que muestra el total de solicitudes permitidas
• Encabezado X-RateLimit-Remaining que muestra las solicitudes restantes en la ventana
• Encabezado X-RateLimit-Reset con la marca de tiempo UTC cuando se reinicia la ventana

Utilice un servicio de limitación de velocidad centralizado (respaldado por Redis) en lugar de límites por instancia para evitar que los atacantes distribuyan solicitudes entre instancias para eludir los límites.

---

Validación de entrada

La validación de entradas en el límite de la API es su primera línea de defensa contra ataques de inyección, desbordamientos de búfer y explotación de la lógica empresarial. Cada dato que ingresa a su API debe validarse en cuanto a tipo, formato, longitud, rango y reglas comerciales.

El top 10 de seguridad de la API de OWASP

El OWASP API Security Top 10 (edición 2023) identifica los riesgos críticos que toda API debe abordar:

Mejores prácticas de validación

Validación de esquemas. Defina esquemas de solicitud (utilizando el esquema JSON, Zod o la especificación OpenAPI) y rechace cualquier solicitud que no se ajuste. Esto detecta datos con formato incorrecto antes de que lleguen a la lógica empresarial.

Consultas parametrizadas. Nunca concatene la entrada del usuario en consultas SQL, NoSQL o LDAP. Utilice consultas parametrizadas o métodos ORM que manejen el escape automáticamente. Esta es una regla de seguridad crítica para todas las plataformas comerciales.

Cumplimiento del tipo de contenido. Solo acepte encabezados de tipo de contenido esperados. Una API que espera JSON debe rechazar XML, datos de formularios y otros tipos de contenido para evitar ataques basados ​​en analizadores.

Filtrado de respuestas. Nunca devuelva registros completos de la base de datos al cliente. Utilice DTO (objetos de transferencia de datos) para definir explícitamente qué campos se incluyen en cada respuesta. Los campos internos como hashes de contraseñas, ID internos y metadatos de auditoría nunca deberían aparecer en las respuestas de la API.

Manejo de errores. Devuelve mensajes de error genéricos a los clientes. Nunca exponga rastros de pila, errores de bases de datos o detalles internos del sistema. Registre errores detallados en el lado del servidor para depurarlos.

---

Patrones de arquitectura de seguridad API

Patrón de puerta de enlace API

Una puerta de enlace API se ubica frente a todos los servicios backend y centraliza las preocupaciones de seguridad transversales:

• Autenticación --- Valida los tokens antes de que las solicitudes lleguen a los servicios backend
• Limitación de velocidad --- Aplica límites en el nivel de puerta de enlace
• Transformación de solicitud/respuesta --- Elimina encabezados confidenciales y agrega encabezados de seguridad
• Registro y monitoreo --- Captura todo el tráfico API para análisis de seguridad
• Integración WAF --- Bloquea patrones de ataque conocidos (inyección SQL, cargas útiles XSS)

Las puertas de enlace API populares incluyen Kong, AWS API Gateway, Azure API Management y Traefik.

Autenticación de servicio a servicio

Las API internas entre microservicios también requieren autenticación. Las opciones incluyen:

• TLS mutuo (mTLS) --- Tanto el cliente como el servidor presentan certificados. Fuerte pero operativamente complejo.
• Tokens de servicio --- Los servicios se autentican con tokens precompartidos. Sencillo pero requiere una distribución segura.
• Malla de servicios --- Istio o Linkerd manejan mTLS automáticamente entre servicios en Kubernetes.
• Credenciales de cliente OAuth2 --- Los servicios se autentican utilizando el ID del cliente y el secreto para obtener tokens de acceso.

Para arquitectura de confianza cero, la autenticación de servicio a servicio es esencial para evitar el movimiento lateral después de una infracción.

---

Monitoreo y Detección de Incidentes

El monitoreo de seguridad de API debe capturar tanto señales técnicas (intentos de autenticación fallidos, patrones de solicitud inusuales) como señales comerciales (cantidades de transacciones anómalas, acceso masivo a datos).

Señales críticas de seguridad de API

• Errores de autenticación --- Aumento en los inicios de sesión fallidos desde una sola IP o dirigidos a una sola cuenta
• Errores de autorización --- 403 respuestas que indican que los usuarios intentan acceder a recursos no autorizados
• Infracciones del límite de tasas --- Se mantuvieron 429 respuestas de la misma fuente
• Volúmenes de datos inusuales --- Operaciones de lectura masiva que sugieren filtración de datos
• Alteración de parámetros --- Enumeración de ID secuencial, valores negativos, prueba de límites
• Anomalías geográficas --- Llamadas API desde regiones inesperadas o patrones de viaje imposibles

Cree paneles que muestren estas señales en tiempo real. Integre con su SIEM para correlación con otros eventos de seguridad. Defina respuestas automatizadas para amenazas de alta confianza: bloquee las direcciones IP que excedan los umbrales de autenticación fallidos, deshabilite temporalmente las cuentas que presenten viajes imposibles y alerte sobre patrones de acceso masivo a datos.

---

Preguntas frecuentes

¿Debería utilizar claves API o tokens OAuth2?

Utilice tokens OAuth2 para cualquier API que proporcione aplicaciones orientadas al usuario o integraciones de terceros. Las claves API solo son aceptables para la comunicación de servidor a servidor donde ambos puntos finales están bajo su control, e incluso entonces, las solicitudes firmadas por HMAC brindan mayor seguridad. Nunca utilice claves API como única autenticación para puntos finales de acceso público.

¿Cómo manejo el control de versiones de API de forma segura?

Utilice versiones basadas en URL (por ejemplo, /api/v2/orders) para mayor claridad y visibilidad. Al dejar de usar una versión, establezca una fecha de caducidad, comuníquesela a los consumidores y supervise el uso. Continúe aplicando parches de seguridad a las versiones obsoletas hasta que se retiren por completo. Nunca deje en ejecución versiones antiguas de API sin parches: se convierten en objetivos fáciles.

¿Qué límites de velocidad debo establecer para una API empresarial?

Comience de manera conservadora y aumente según los datos de uso legítimo. Para los puntos finales de autenticación, el estándar es de 5 a 10 solicitudes por minuto por IP. Para los puntos finales de datos, entre 100 y 500 solicitudes por minuto por usuario autenticado cubren la mayoría de los casos de uso empresarial. Supervise las respuestas 429 para identificar límites que sean demasiado restrictivos y supervise los patrones de abuso para identificar límites que sean demasiado generosos.

¿Cómo protejo los webhooks de servicios de terceros?

Verifique las firmas de webhooks utilizando HMAC-SHA256 con un secreto compartido. Valide la marca de tiempo para evitar ataques de repetición (rechace eventos de más de 5 minutos). Procese los webhooks de forma asincrónica para evitar la denegación de servicio basada en el tiempo de espera. Registre todos los eventos de webhook con fines de auditoría. Valide el esquema de carga útil antes de procesarlo.

---

¿Qué sigue?

La seguridad de API no es una característica que se agrega al final del desarrollo; es un principio de diseño que debe estar presente desde el primer punto final. Comience con una autenticación sólida (OAuth2/OIDC), aplique la autorización en cada punto de acceso a recursos, implemente limitaciones de velocidad en todos los tipos de puntos finales y valide cada entrada que cruce los límites de su API.

ECOSIRE incorpora seguridad en cada integración de API. Nuestra plataforma OpenClaw AI implementa solicitudes firmadas por HMAC, limitación de velocidad y protección SSRF de forma predeterminada, mientras que nuestras integraciones Odoo ERP utilizan OAuth2/OIDC con control de acceso basado en roles. Comuníquese con nuestro equipo para proteger las API de su plataforma empresarial.

---

Publicado por ECOSIRE --- ayudando a las empresas a escalar con soluciones impulsadas por IA en Odoo ERP, Shopify eCommerce y OpenClaw AI.