Firewall configurado, HTTPS activo, sitio actualizado. Aun así, los datos de tus clientes pueden estar a una sola solicitud de distancia de cualquier persona en internet. El motivo casi siempre es el mismo: las APIs. En este artículo mostramos dónde están las fallas que más exponen a las empresas hoy, cómo se corrigen en el código y en la infraestructura y qué evaluar antes de que el problema se convierta en incidente.

El punto ciego de la mayoría de las empresas

Toda integración moderna pasa por una API: la app que consulta pedidos, la tienda online que habla con el ERP, el CRM que recibe mensajes de WhatsApp, el socio que toma tu catálogo. Según Cloudflare Radar, el 58% del tráfico HTTP dinámico de internet ya es tráfico de API.

El problema es que la seguridad no acompañó ese crecimiento. Gartner preveía que, para 2025, menos de la mitad de las APIs corporativas estarían gestionadas. En la práctica, muchas empresas no saben cuántas APIs tienen en producción, quién las consume ni qué datos devuelven.

Ese es exactamente el espacio que explotan los atacantes. El sitio principal suele recibir firewall, pruebas y atención. La API se creó para una integración con plazos ajustados y nunca más se revisó. Por APIs salieron a la luz casos como la recolección de datos de unos 700 millones de perfiles de LinkedIn y las fallas explotadas durante años en T-Mobile.

Qué está en juego para el negocio

La seguridad de APIs no es un tema solo del equipo técnico. Una falla aquí tiene un costo directo:

  • Leyes de privacidad: en Brasil, una filtración de datos personales puede generar sanciones de la ANPD de hasta el 2% de la facturación, con un tope de R$ 50 millones por infracción, además de la obligación de avisar a los afectados. El RGPD y leyes similares prevén multas comparables.
  • Operación detenida: una API sin límite de uso puede caer por exceso de solicitudes, y con ella caen la app, el checkout y las integraciones.
  • Competencia: APIs demasiado abiertas permiten que terceros copien catálogo, precios y stock de forma automatizada.
  • Confianza: un cliente que recibe el aviso de que sus datos se filtraron difícilmente vuelve a comprar.

Por qué proteger el sitio no alcanza

Las herramientas pensadas para sitios miran formularios, scripts y navegación. La API funciona de otra forma: recibe y devuelve datos puros (JSON), la consumen sistemas y no personas y habla directamente con la base de datos. Una llamada maliciosa a una API suele ser idéntica a una legítima. La diferencia está en el contexto: quién pide, qué y con qué frecuencia.

Por eso la regla fundamental es: toda operación de API debe validar la identidad y el permiso de quien llama, en cada solicitud. Estar autenticado no significa estar autorizado.

Las 5 fallas que más exponen a las empresas

La referencia del mercado en el tema es el OWASP API Security Top 10, la lista de las vulnerabilidades de API más explotadas. Las cinco de abajo concentran la mayor parte de los incidentes y son las primeras que evaluamos en un diagnóstico.

1. Acceso a datos de otros usuarios (OWASP API1: BOLA)

Es la falla número uno del ranking. La API confirma que el usuario inició sesión, pero no confirma que el registro pedido le pertenezca:

GET /api/pedidos/1042   → 200 OK  (pedido del usuario)
GET /api/pedidos/1043   → 200 OK  (pedido de otro cliente)

Con un script simple, alguien recorre todos los IDs y descarga la base entera. La corrección está en el código: toda consulta filtra por el dueño del recurso, que viene del token, nunca de lo que envía el cliente.

[Authorize]
[HttpGet("{id:int}")]
public async Task<IActionResult> Obtener(int id)
{
    var clienteId = User.FindFirstValue(ClaimTypes.NameIdentifier);

    var pedido = await _db.Pedidos
        .Where(p => p.Id == id && p.ClienteId == clienteId)
        .Select(p => new PedidoDto(p.Id, p.Estado, p.Total))
        .FirstOrDefaultAsync();

    // 404 en lugar de 403: no confirma que el pedido existe
    return pedido is null ? NotFound() : Ok(pedido);
}

2. Autenticación frágil (OWASP API2)

Tokens que nunca expiran, claves de API fijas en el código de la app, endpoints de login sin protección contra prueba y error. Basta un token filtrado para que alguien actúe en nombre del cliente.

Cómo lo resolvemos: tokens JWT u OAuth 2.0 de corta duración, con firma, emisor y vencimiento verificados en cada solicitud; mTLS para integraciones entre servidores; y bloqueo progresivo en login y recuperación de contraseña.

3. Exposición excesiva de datos (OWASP API3)

La pantalla muestra el nombre del cliente, pero la respuesta de la API devuelve documento, teléfono, dirección y a veces hasta el hash de la contraseña. Cualquiera que abra las herramientas del navegador ve todo.

Cómo lo resolvemos: la API nunca devuelve la entidad de la base directamente. Cada endpoint tiene un DTO solo con los campos necesarios, como el PedidoDto del ejemplo anterior. En el borde, la detección de datos sensibles alerta cuando aparecen documentos, tarjetas o credenciales en una respuesta.

4. Consumo sin límite (OWASP API4)

Sin límite de solicitudes, la API queda abierta a fuerza bruta en contraseñas, scraping de catálogo y ataques de denegación de servicio. Un listado sin paginación permite descargar millones de registros en una llamada.

Cómo lo resolvemos: rate limiting en el código y en el borde, con límites calibrados según el tráfico real de cada endpoint, y paginación obligatoria. Los frameworks modernos ya lo traen listo, sea en .NET, Node.js, Java, PHP o Python. Un ejemplo en ASP.NET Core:

builder.Services.AddRateLimiter(o =>
{
    o.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
    o.AddFixedWindowLimiter("api", l =>
    {
        l.PermitLimit = 100;                // 100 solicitudes
        l.Window = TimeSpan.FromMinutes(1); // por minuto
    });
});

app.MapControllers().RequireRateLimiting("api");

5. APIs olvidadas (OWASP API9)

La /api/v1 que debió apagarse, el endpoint de prueba que llegó a producción, la integración de un proveedor antiguo. Son las llamadas shadow APIs: no aparecen en ninguna documentación, no reciben correcciones y son las favoritas de quien busca una puerta abierta.

Cómo lo resolvemos: inventario continuo a partir del tráfico real, documentación OpenAPI generada por el propio código, versiones antiguas con fecha de apagado y un responsable definido para cada API.

Seguridad en capas: código, borde y monitoreo

Ninguna herramienta aislada resuelve el problema. La protección que funciona combina tres capas:

  1. En el código: autorización por recurso, DTOs, validación de entrada y rate limiting. Es donde se elimina la causa de la falla.
  2. En el borde: un gateway de API con WAF, como el de Cloudflare, delante del servidor. Valida tokens, aplica límites, bloquea ataques conocidos y descubre endpoints no documentados antes de que el tráfico llegue a tu infraestructura.
  3. En el monitoreo: logs de auditoría de quién accedió a qué y cuándo, alertas de comportamiento anormal y registros que cumplen las exigencias de las leyes de privacidad.
EnfoqueIndicado paraLimitación
Observabilidad de APIsEntender el tráfico en preproducciónIdentifica, pero no bloquea
Gestión del ciclo de vidaSectores regulados y APIs heredadasFuerte en gobernanza, débil en protección activa
Protección de aplicaciones web y APIs (WAAP)APIs en producciónDebe combinarse con correcciones en el código

¿Tu empresa está expuesta? Responde con sinceridad

  • ¿Tienes una lista actualizada de todas las APIs en producción, incluidas las de proveedores?
  • ¿Cada consulta verifica que el registro pertenece al usuario del token?
  • ¿Los tokens expiran y se validan en cada solicitud?
  • ¿Las respuestas devuelven solo los campos que usa la aplicación?
  • ¿Hay límite de solicitudes por endpoint y paginación en los listados?
  • ¿Existen logs que muestran quién accedió a qué datos personales?
  • ¿Hay una capa de protección (WAF o gateway) delante de las APIs?

Si respondiste “no” o “no sé” a cualquier punto, tu API probablemente tiene una puerta abierta, y es mejor que la encuentres tú antes que otra persona.

Cómo CPW protege tus APIs

Desde hace más de 10 años diseñamos, desarrollamos y mantenemos APIs en la tecnología que más sentido tiene para cada negocio, y la seguridad es parte del proyecto desde la primera línea de código, no un ajuste al final. Para empresas que ya tienen APIs en producción, sea cual sea el lenguaje o la nube, el trabajo sigue tres etapas:

  1. Diagnóstico: inventario de las APIs y pruebas basadas en el OWASP API Security Top 10, con un informe de riesgos priorizado por impacto en el negocio.
  2. Corrección: ajustes en el código, como autorización por recurso, DTOs, tokens y rate limiting, sin detener la operación.
  3. Protección continua: configuración de la capa de borde, monitoreo y hosting gestionado con HTTPS y CDN.

¿Quieres saber si las APIs de tu empresa están expuestas? Habla con nosotros por WhatsApp y agenda un diagnóstico.

Datos de Cloudflare Radar y Gartner citados a partir del eBook “Guía sobre seguridad de APIs para CISOs” de Cloudflare (2023). Clasificación de vulnerabilidades: OWASP API Security Top 10 (2023).