Lo m\u00e1s importante en resumen<\/p>\n
- \n
- La superficie de ataque se ha trasladado.<\/strong> En lugar de una sola p\u00e1gina web, hoy son docenas de interfaces detr\u00e1s de apps, integraciones y conexiones con socios, cada una con su propio acceso a los datos.<\/li>\n
- BOLA encabeza la lista de OWASP.<\/strong> Falta de autorizaci\u00f3n a nivel de objeto: basta con incrementar una ID ajena. Es uno de los errores m\u00e1s comunes en APIs y rara vez est\u00e1 en el c\u00f3digo escrito a prop\u00f3sito.<\/li>\n
- Solo se protege lo que se conoce.<\/strong> Las APIs sombra y zombi de versiones antiguas son el problema silencioso. Un inventario de APIs es el paso uno, no el paso cinco.<\/li>\n
- Los ant\u00eddotos son discretos.<\/strong> Autorizaci\u00f3n por objeto, limitaci\u00f3n de tasa, validaci\u00f3n de esquemas en la pasarela. Se basa en configuraci\u00f3n y disciplina, no en un costoso dispositivo.<\/li>\n<\/ul>\n<\/div>\n
Relacionado:<\/span>El kernel compartido como brecha: c\u00f3mo se producen los escapes de contenedores<\/a> \/<\/span> 14 paquetes npm maliciosos en 4 horas: la est\u00e1tica ya no basta<\/a><\/p>\n
Por qu\u00e9 la superficie de ataque se ha desplazado detr\u00e1s de la app<\/h2>\n
Hace diez a\u00f1os, la p\u00e1gina web era la puerta de entrada. Hoy, la p\u00e1gina web es solo la fachada; detr\u00e1s trabajan las interfaces. La app m\u00f3vil se comunica con una API, el portal de socios extrae datos a trav\u00e9s de una API, el ERP se sincroniza mediante una API, y el asistente de IA que alguien acaba de integrar tambi\u00e9n llama a una API. Cada una de estas conexiones es una puerta por la que entran y salen datos.<\/p>\n
\n![\"Primer](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/06\/st-inline-260608-hero.jpg\")
Las APIs suelen crearse r\u00e1pidamente en el c\u00f3digo para servir a una app. La revisi\u00f3n de seguridad suele posponerse. Foto: Godfrey Atima \/ Pexels<\/figcaption><\/figure>\n Lo inc\u00f3modo es que estas puertas son m\u00e1s invisibles que la p\u00e1gina de inicio. Un pentest analiza la aplicaci\u00f3n web, pero un endpoint de API que solo usa una app puede pasar desapercibido. Justo aqu\u00ed no me f\u00edo de la sensaci\u00f3n de tenerlo todo controlado. M\u00e1s veces de las que me gustar\u00eda, he encontrado una API de la que el equipo juraba que ya no exist\u00eda.<\/p>\n
BOLA y la lista OWASP: d\u00f3nde falla en concreto<\/h2>\n
\u00bfQu\u00e9 es la seguridad de APIs?<\/strong> La seguridad de APIs abarca las medidas que protegen una interfaz de programaci\u00f3n frente a usos indebidos: autenticaci\u00f3n correcta, autorizaci\u00f3n a nivel de objeto y funci\u00f3n, limitaci\u00f3n de la carga y validaci\u00f3n de los datos transmitidos. Se diferencia de la seguridad web cl\u00e1sica porque, en una API, cada llamada impacta directamente en la l\u00f3gica de negocio, sin una capa de protecci\u00f3n intermedia.<\/p>\n
El Top 10 de Seguridad de APIs de OWASP es el mapa m\u00e1s \u00fatil para identificar las vulnerabilidades que realmente aparecen en la pr\u00e1ctica. En primer lugar est\u00e1 BOLA, *Broken Object Level Authorization* (Autorizaci\u00f3n rota a nivel de objeto). El servidor verifica si alguien est\u00e1 autenticado, pero no si el objeto solicitado le pertenece. Una llamada a \/api\/orders\/1043<\/span> devuelve el propio pedido, mientras que \/api\/orders\/1044<\/span> muestra el de un tercero. No se necesita ninguna herramienta, basta con un contador.<\/p>\n
Justo al lado se encuentran la autenticaci\u00f3n rota, donde los tokens tienen una vida demasiado larga o se validan de forma laxa, y el consumo ilimitado de recursos, en el que un \u00fanico cliente puede saturar la interfaz con peticiones descontroladas. Ninguna de estas brechas es ex\u00f3tica. Surgen porque una API se construye r\u00e1pido para dar servicio a una app, y las cuestiones de seguridad se posponen para \u00abm\u00e1s tarde\u00bb. En la pr\u00e1ctica, ese \u00abm\u00e1s tarde\u00bb rara vez llega.<\/p>\n
\n\n\n
\n \nVisi\u00f3n cl\u00e1sica del per\u00edmetro<\/th>\n Realidad de las APIs<\/th>\n<\/tr>\n<\/thead>\n \n Protege la aplicaci\u00f3n web visible<\/td>\n Docenas de endpoints, muchos de ellos sin documentar<\/td>\n<\/tr>\n \n Ataque a trav\u00e9s de campos de entrada y sesiones<\/td>\n Ataque mediante IDs incrementales, debilidades en tokens y carga<\/td>\n<\/tr>\n \n Un WAF cubre gran parte<\/td>\n La autorizaci\u00f3n debe implementarse por objeto en la aplicaci\u00f3n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n APIs en la sombra: solo se protege lo que se conoce<\/h2>\n
El mayor problema rara vez es la interfaz de la que todos hablan, sino aquella que nadie recuerda. Las *shadow APIs* surgen cuando un equipo crea r\u00e1pidamente un endpoint y nunca lo incluye en la documentaci\u00f3n oficial. Las *zombie APIs* son versiones antiguas que siguen activas tras un lanzamiento porque \u00abno molestan a nadie\u00bb. Ambas circulan sin parches, sin revisiones y, a menudo, sin reglas de acceso actualizadas.<\/p>\n
Por eso la seguridad de APIs no empieza con una herramienta, sino con una lista. Quien no conoce sus endpoints no puede protegerlos, monitorizarlos ni desactivarlos. Esto suena obvio, pero es el paso que la mayor\u00eda omite porque parece un trabajo tedioso. Sin este esfuerzo previo, el resto no es m\u00e1s que cosm\u00e9tica.<\/p>\n
Cinco pasos que soportan la mayor carga<\/h2>\n
La buena noticia para las pymes: la seguridad de las API rara vez requiere un nuevo appliance caro. Exige hacer unas pocas cosas de manera consistente. Estos cinco pasos soportan la mayor parte de la carga.<\/p>\n
- \n
- Llevar un inventario.<\/strong> Registrar cada endpoint, incluidos los antiguos y los no oficiales. Un gateway o un escaneo sencillo hacen visible lo que realmente es accesible.<\/li>\n
- Verificar la autorizaci\u00f3n por objeto.<\/strong> En cada llamada, no solo preguntar si alguien est\u00e1 autenticado, sino si le pertenece el objeto solicitado. Esta es la respuesta directa a BOLA.<\/li>\n
- Centralizar la autenticaci\u00f3n en el gateway.<\/strong> Aplicar de forma centralizada la verificaci\u00f3n de tokens, tiempos de expiraci\u00f3n y scopes, en lugar de implementarlos de nuevo y con posibles errores en cada aplicaci\u00f3n.<\/li>\n
- Establecer rate-limiting.<\/strong> Un l\u00edmite superior por cliente dificulta el r\u00e1pido ensayo de IDs y evita la sobrecarga por un \u00fanico solicitante. La soluci\u00f3n real contra BOLA sigue siendo la autorizaci\u00f3n por objeto del paso dos.<\/li>\n
- Validar las entradas seg\u00fan el esquema.<\/strong> Lo que no se ajusta a la estructura esperada se rechaza antes de llegar a la l\u00f3gica de negocio.<\/li>\n<\/ol>\n
Nada de esto es nuevo, y precisamente ese es el punto. Las brechas en las API no surgen porque falte conocimiento, sino porque la interfaz se construy\u00f3 bajo presi\u00f3n de tiempo y la protecci\u00f3n se pospuso. Configurar estos ajustes una vez como est\u00e1ndar es m\u00e1s econ\u00f3mico que el primer incidente en el que alguien haya extra\u00eddo los pedidos de toda la clientela.<\/p>\n
El primer paso sin equipo de seguridad<\/h2>\n
Quien no tenga un equipo de seguridad no empieza con la herramienta m\u00e1s cara, sino con la pregunta m\u00e1s inc\u00f3moda: \u00bfqu\u00e9 interfaces tenemos realmente y qui\u00e9n puede acceder a qu\u00e9 datos a trav\u00e9s de ellas? La respuesta a esto suele revelar m\u00e1s que cualquier esc\u00e1ner comprado. Un API Gateway, que muchos proveedores cloud incluyen de serie, centraliza la autenticaci\u00f3n, el rate-limiting y el logging en un solo lugar y convierte puertas dispersas en una entrada controlada.<\/p>\n
El resto es cuesti\u00f3n de actitud. Una interfaz no est\u00e1 terminada hasta que alguien haya decidido qui\u00e9n puede invocarla y qu\u00e9 ocurre si alguien lo hace con demasiada frecuencia. Mientras falte esta decisi\u00f3n, la API no es un producto, sino una ventana abierta que a\u00fan no ha encontrado nadie.<\/p>\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 diferencia la seguridad de API de la seguridad web cl\u00e1sica?<\/h3>\n
La seguridad web cl\u00e1sica protege una interfaz tras la que se encuentra la l\u00f3gica. Una API no tiene interfaz; cada llamada impacta directamente en la l\u00f3gica. Por eso no basta con un WAF: el control real, especialmente la autorizaci\u00f3n por objeto, debe residir en la propia aplicaci\u00f3n.<\/p>\n
\u00bfQu\u00e9 es BOLA y por qu\u00e9 es tan com\u00fan?<\/h3>\n
BOLA significa Broken Object Level Authorization (Autorizaci\u00f3n rota a nivel de objeto). El servidor verifica si un usuario est\u00e1 autenticado, pero no si le pertenece el objeto solicitado. Quien incremente una ID en la petici\u00f3n puede ver datos ajenos. Es com\u00fan porque esta verificaci\u00f3n se olvida f\u00e1cilmente cuando una API se desarrolla r\u00e1pido para una app.<\/p>\n
\u00bfNecesito una herramienta cara de seguridad para API?<\/h3>\n
Al principio, no. Un inventario de API, autorizaci\u00f3n por objeto, un gateway para autenticaci\u00f3n y rate-limiting, adem\u00e1s de la validaci\u00f3n de esquemas, cubren la mayor parte. Las herramientas especializadas ayudan a escalar y a detectar Shadow-APIs, pero no sustituyen los fundamentos.<\/p>\n
\u00bfQu\u00e9 son las Shadow-APIs y las Zombie-APIs?<\/h3>\n
Las Shadow-APIs son endpoints creados pero nunca documentados. Las Zombie-APIs son versiones antiguas que siguen activas tras un lanzamiento. Ambas escapan al control y suelen tener reglas de acceso obsoletas. Son una de las principales razones por las que un inventario completo es el primer paso.<\/p>\n
\u00bfPor d\u00f3nde deber\u00eda empezar una pyme sin equipo de seguridad?<\/h3>\n
Con un inventario: \u00bfqu\u00e9 interfaces existen y qui\u00e9n puede acceder a qu\u00e9 datos a trav\u00e9s de ellas? Despu\u00e9s, utilizar un API Gateway, que muchos proveedores cloud incluyen, para centralizar la autenticaci\u00f3n, el rate-limiting y el logging. Es m\u00e1s econ\u00f3mico y efectivo que un esc\u00e1ner comprado sin haber sentado las bases.<\/p>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h3>\n
- Verificar la autorizaci\u00f3n por objeto.<\/strong> En cada llamada, no solo preguntar si alguien est\u00e1 autenticado, sino si le pertenece el objeto solicitado. Esta es la respuesta directa a BOLA.<\/li>\n
- BOLA encabeza la lista de OWASP.<\/strong> Falta de autorizaci\u00f3n a nivel de objeto: basta con incrementar una ID ajena. Es uno de los errores m\u00e1s comunes en APIs y rara vez est\u00e1 en el c\u00f3digo escrito a prop\u00f3sito.<\/li>\n