La seguridad en APIs se ha convertido en el punto ciego de buena parte de los proyectos de desarrollo a medida: el equipo de marketing pide una integración con el CRM, el ecommerce o el ERP, y esa conexión sale a producción sin que nadie revise cómo se autentica ni qué datos expone. En Barcelona, agencias y departamentos técnicos gestionan cada vez más integraciones —pasarelas de pago, CRM, plataformas de anuncios, ERP— y cada una añade un endpoint nuevo que vigilar. Este artículo repasa los diez riesgos que marca OWASP y qué debe exigir un responsable de marketing o un equipo técnico antes de dar por buena una integración.
Seguridad en APIs: qué significa en marketing
Una API es la puerta por la que un sistema externo lee o escribe datos en tu web: el CRM consulta leads, la plataforma de anuncios recibe conversiones, el ERP actualiza el stock del ecommerce. Cada una de esas puertas queda abierta las 24 horas, y quien la programa decide qué puede pasar por ella y qué se queda fuera.
La seguridad en APIs no es un capítulo aparte del desarrollo: es la parte que decide si esa puerta deja pasar solo lo que debe o cualquier petición bien formada. Un formulario de captación conectado sin control de acceso puede devolver, además del lead que pediste, los datos de cualquier otro registro con solo cambiar un número en la URL. No es un fallo exótico: encabeza el ranking OWASP desde 2019 y sigue ahí en la revisión de 2023.
La seguridad en APIs es el conjunto de controles que verifican quién pide un dato, qué dato recibe y cuántas veces puede pedirlo, aplicados a cada conexión automática entre sistemas.
Los 10 riesgos OWASP en APIs
OWASP actualizó su ranking de riesgos en API en 2023, el primero desde 2019, y lo ordena por probabilidad de explotación en producción, no por gravedad teórica. La revisión sumó tres categorías nuevas: acceso sin límite a flujos de negocio sensibles, falsificación de peticiones del lado del servidor y consumo inseguro de APIs de terceros, justo lo que ocurre cuando conectas un CRM o una pasarela de pago sin revisar cómo responde ante un fallo.
| Riesgo OWASP | Qué explota | Ejemplo en marketing |
|---|---|---|
| API1: objeto sin control de acceso | Accede a datos de otro usuario cambiando un ID | Ver leads de otra campaña cambiando el id en la URL |
| API2: autenticación rota | Roba o adivina tokens de sesión | Token de API sin caducidad filtrado en un repositorio |
| API3: propiedad sin control de acceso | Expone o modifica campos de más | El CRM devuelve el email aunque el formulario solo pida el nombre |
| API4: consumo de recursos sin límite | Satura la API con peticiones masivas | Un scraper vacía el catálogo en una tarde |
| API5: función sin control de acceso | Ejecuta acciones de otro rol | Un usuario borra campañas con el endpoint del administrador |
| API6: flujos de negocio sin control | Automatiza un proceso pensado para una persona | Un bot agota el stock de una oferta de lanzamiento |
| API7: falsificación de peticiones del servidor | Obliga al servidor a llamar a una URL ajena | El webhook de pago acepta una URL manipulada |
| API8: configuración incorrecta | Deja abierto lo que debía estar cerrado | El entorno de pruebas queda accesible con credenciales por defecto |
| API9: inventario incompleto | Deja endpoints antiguos activos | El formulario anterior sigue en línea sin parchear |
| API10: consumo inseguro de terceros | Confía en datos externos sin validarlos | Un plugin de reseñas inyecta HTML sin sanear |
El 78% de los ataques a APIs explota alguno de estos diez puntos, según el informe de Akamai sobre el estado de internet de 2026: no hace falta un fallo original, basta con que nadie haya revisado la lista.
Autenticación rota: el fallo más frecuente
La autenticación rota ocupa el segundo puesto del ranking OWASP desde 2019 y sigue ahí en la revisión de 2023: es el fallo que más se repite en integraciones hechas deprisa. No es solo dejar una contraseña por defecto: incluye tokens que no caducan nunca, claves de API compartidas entre el entorno de pruebas y producción, o sistemas que siguen aceptando un token aunque el usuario haya cambiado la contraseña.
En una integración de marketing esto se traduce en credenciales que viajan por Slack, quedan en un documento compartido o se copian en varios proyectos sin que nadie las revoque cuando termina el contrato con la agencia que las generó.
Tokens robados: el vector más barato de explotar
Wallarm sitúa el robo de tokens y credenciales como el vector más barato de explotar, porque no exige encontrar una vulnerabilidad de código: basta con una clave filtrada. Su informe de 2026 registra un aumento del 113% interanual en el volumen medio de ataques diarios por organización, de 121 a 258 intentos, y atribuye buena parte del salto a la reutilización de tokens en integraciones con terceros.
La corrección no es compleja: tokens con caducidad corta, uno distinto por integración y por entorno, y renovación automática en lugar de una clave fija copiada en un documento. Cuesta una tarde del equipo de desarrollo y evita que una filtración de hace dos años siga siendo válida hoy.
Qué exponen las APIs sin control de acceso
La autorización rota a nivel de propiedad —API3 en el ranking OWASP— no bloquea el acceso: deja pasar la petición pero devuelve más campos de los que pide el formulario. Qué campos son sensibles cambia mucho según el sector, y ahí el mismo fallo pesa de forma distinta.
Ecommerce: márgenes y stock al descubierto
En un ecommerce, el endpoint que calcula el precio final de un pedido suele devolver también el coste de compra o el margen aplicado, porque programarlo así es más rápido que filtrar los campos en el servidor. Un competidor con conocimientos técnicos básicos puede leer esa respuesta desde las herramientas de desarrollador del navegador sin tocar el código. Lo mismo pasa con el stock: una API pensada para mostrar «quedan pocas unidades» a veces devuelve la cifra exacta por almacén, un dato que la cadena de suministro no quiere público. Filtrar cada respuesta al mínimo necesario corrige el fallo sin tocar el resto de la integración.
Sector industrial: telemetría y datos de planta
En el sector industrial, las integraciones conectan sensores, líneas de producción y sistemas de mantenimiento con paneles accesibles desde fuera de la planta. Una API de telemetría mal acotada puede exponer, además de lo que ve el cliente del panel comercial, los parámetros operativos de la maquinaria: temperaturas, ritmos de producción, paradas programadas. Ese dato vale para un competidor que quiera estimar tu capacidad real, y en instalaciones críticas el mismo fallo abre la puerta a manipular un parámetro en lugar de solo leerlo. La corrección es la misma que en ecommerce —limitar cada respuesta a los campos que el cliente final necesita— pero el coste de no aplicarla es mayor, porque el dato expuesto no es comercial: es operativo.
Qué debe auditar tu proveedor de desarrollo
Antes de dar por buena una integración, pide a quien la desarrolla que documente cinco puntos concretos, el equivalente a una auditoría de seguridad informática básica. No hace falta un informe formal: basta una respuesta clara a cada uno.
- Qué autenticación usa cada endpoint y quién puede rotar esas credenciales.
- Qué campos devuelve cada respuesta y si alguno sobra para el uso que le vas a dar.
- Qué límite de peticiones tiene configurado y qué ocurre cuando se supera.
- Si el entorno de pruebas es accesible desde internet o solo desde la red interna.
- Qué API de terceros consume la integración y si valida lo que recibe de ella.
Estos cinco puntos cubren ocho de los diez riesgos del ranking OWASP sin necesitar vocabulario técnico: son preguntas que un responsable de marketing puede formular y entender la respuesta. Si el proveedor no las contesta con precisión, la integración no está lista para producción, aunque funcione en la demo. Algunas empresas prefieren delegar esta revisión en una consultoría de sistemas IT externa que audite las integraciones sin depender del mismo equipo que las construyó.
Coste de una vulnerabilidad de API sin corregir
El coste de una brecha vinculada a APIs supera de media los cinco millones de dólares en organizaciones con un uso intensivo de estas integraciones, según Wallarm en su informe de 2026, y cada hora de caída por un incidente de este tipo cuesta a la empresa cifras de seis dígitos en ingresos perdidos. Akamai sitúa el coste medio por incidente algo por debajo, en torno a los 700.000 dólares, y coincide en el diagnóstico de fondo: solo el 23% de las organizaciones mantiene un inventario completo de sus APIs, frente al 40% de hace unos años.
Para una empresa mediana esas cifras no son directamente extrapolables, pero la lógica sí lo es: cuanto más tarde se detecta un endpoint mal protegido, más caro sale corregirlo, porque para entonces ya hay datos reales circulando por él. Contratar el desarrollo de software con un proveedor que documenta y revisa cada integración sale más barato que reaccionar después del incidente.
Preguntas frecuentes sobre seguridad en APIs
¿Qué es una API insegura?
Es una integración que acepta peticiones sin verificar bien quién las hace, qué datos pide o cuántas veces las repite. No hace falta que tenga un error de programación visible: basta con que confíe en exceso en quien llama al otro lado.
¿Cómo sé si mi web tiene APIs sin proteger?
Pide al equipo de desarrollo un listado de las integraciones activas —CRM, pasarela de pago, plataformas de anuncios— y para cada una, qué autenticación usa y qué límite de peticiones tiene. Si ese listado no existe, crearlo es el primer paso antes de auditar nada más.
¿Cuánto cuesta auditar la seguridad de una integración?
Depende del número de endpoints y de si ya hay documentación previa. Revisar las integraciones críticas —pagos, CRM, formularios— suele resolverse en unos días de trabajo técnico, muy por debajo del coste medio de un incidente, que ronda los 700.000 dólares según Akamai.
¿El ranking OWASP cambia cada año?
No: la última revisión completa es de 2023, la primera desde 2019. OWASP no lo actualiza por calendario, sino cuando el patrón de ataques reales cambia lo suficiente para justificar una lista nueva, así que sigue vigente en 2026.
Fuente: OWASP API Security Top 10 (2023)