Seguridad API, así es el top 10 de riesgos de OWASP

El Top 10 de seguridad API de OWASP pone el foco sobre las principales vulnerabilidades presentes en las interfaces de programación de aplicaciones

Pocos acrónimos son más relevantes para explicar la digitalización de nuestro mundo que API. Detrás de estas tres letras se esconde el concepto Application Programming Interfaces. Estas interfaces de programación de aplicaciones se tratan de especificaciones o reglas que sirven para facilitar la comunicación entre diferentes aplicaciones. Así, las API definen y protocolizan cómo interacciona un software con otro. Como consecuencia de ello, las API se han convertido en elementos clave tanto a la hora de desarrollar nuevo software como en lo relativo a la conexión entre aplicaciones.

El papel que ocupan las API en el mundo del desarrollo ha atraído a los ciberdelincuentes, situándolas en el punto de mira de los ataques. Por ello, la fundación OWASP, un referente global en la elaboración de materiales y estándares en materia de ciberseguridad, publicó en 2019 la primera versión del Top 10 de seguridad API, centrada en listar las 10 grandes vulnerabilidades que pueden estar presentes en las API y ser explotadas por los actores hostiles.

A principios de junio de 2023, ha visto la luz la nueva versión del Top 10 de seguridad API de OWASP, que incorpora todos los cambios que se han producido en los últimos cuatro años en torno a las API y las amenazas que deben tener en cuenta desarrolladores, especialistas en ciberseguridad y empresas.

A continuación, vamos a desgranar las claves de la versión de 2023 del Top 10 de seguridad API de OWASP y cómo este ranking puede servir de ayuda a la hora de proteger a las API a lo largo de todo su ciclo de vida.

1. Las API, un elemento fundamental en la digitalización del mundo

Vivimos rodeados de API, aunque no están al alcance de nuestra vista. Las API posibilitan que podamos pagar una compra en un ecommerce, tengamos a nuestra disposición la información meteorológica en una app de nuestro móvil o podamos reservar a golpe de clic una habitación de hotel para disfrutar de una escapada de fin de semana con nuestra pareja.

La definición de las API con la que comenzamos este artículo evidencia su relevancia en el desarrollo de software a raíz del salto al Cloud y el auge del Software as a Service (SaaS), las apps móviles y los dispositivos IoT.

De hecho, las API han revolucionado el desarrollo de aplicaciones al permitir disminuir los costes y reducir el tiempo que se necesita para desarrollarlas. Gracias a las API no es necesario desarrollar software desde cero y se incrementa la capacidad de innovación y escalabilidad.

En la actualidad, las API son empleadas en aplicaciones empresariales de toda clase de sectores económicos (finanzas, transporte, comercio, salud), ya estén desarrolladas para ser usadas por clientes, socios comerciales o de forma interna.

Al facilitar la comunicación entre aplicaciones y la transmisión de datos, las API se han convertido en un target prioritario para los criminales que buscan cometer acciones maliciosas contra el software empresarial y cumplir con sus objetivos delictivos: robo, secuestro y exfiltración de datos, paralización de la operatividad de una empresa…

La detección de vulnerabilidades relacionadas con API inseguras se ha convertido en una cuestión de vital importancia para las compañías hoy en día. De ahí que la puesta en marcha de una auditoría de seguridad web sea fundamental para encontrar debilidades en las API, antes de que sean explotadas por actores hostiles.

2. Los 10 riesgos de seguridad de las API más importantes

Al igual que sucede con el resto de rankings de OWASP, el Top 10 de seguridad API es fruto de una profusa investigación sobre incidentes de seguridad en torno a API y de las aportaciones realizadas por expertos de todo el mundo. El objetivo de la nueva versión del Top 10 de seguridad API es listar los riesgos específicos de las API que las empresas, los desarrolladores y los profesionales de ciberseguridad deben tener en cuenta para fortalecer su seguridad.

Por ello, el Top 10 de seguridad API no es excluyente con respecto a otros documentos de OWASP como el Top 10 de vulnerabilidades de aplicaciones web. Las aplicaciones que emplean API pueden presentar vulnerabilidades directamente ligadas a ellas, pero también son susceptibles de presentar alguna de las debilidades genéricas del Top 10 de aplicaciones web.

A la hora de abordar cada uno de los riesgos del top, OWASP aporta:

• Una descripción del riesgo
• Ejemplos de escenarios en los que la vulnerabilidad puede ser explotada por actores hostiles
• Recomendaciones para prevenir su presencia en las API

Este Top 10 de seguridad API está compuesto por los siguientes riesgos:

1. Autorización rota a nivel de objeto
2. Autenticación incorrecta
3. Autorización rota a nivel de propiedad de objeto
4. Consumo de recursos no restringido
5. Autorización rota a nivel de función
6. Acceso sin restricciones a flujos empresariales sensibles
7. Falsificación de peticiones del lado del servidor
8. Incorrecta configuración de la seguridad
9. Gestión inadecuada del inventario
10. Consumo inseguro de API

2.1. Autorización rota a nivel de objeto

La autorización a nivel de objeto es un mecanismo esencial en el funcionamiento de las API, puesto que sirve para controlar el acceso de los usuarios y validar que cada usuario goza de los permisos necesarios para realizar una determinada acción sobre el objeto solicitado.

Así, cada endpoint de la API recibe un ID de un objeto y realiza una acción sobre él, debe llevar a cabo una comprobación para asegurar la autorización a nivel de objeto.

¿Qué sucede si este mecanismo falla? Se puede producir la divulgación de información y se abre la puerta a la manipulación y destrucción de datos.

OWASP señala que esta vulnerabilidad es fácilmente explotable por los actores hostiles. Puesto que los delincuentes pueden explotar los endpoints de una API que presentan esta debilidad. Este problema es muy habitual en las aplicaciones basadas en API, de ahí su primera posición en el Top 10 de seguridad API.

2.1.1. Prevención

Para prevenir esta vulnerabilidad, el Top 10 de seguridad API de OWASP recomienda:

• Implantar un mecanismo de autorización adecuado que se base en las políticas y la jerarquía de usuarios.
• Utilizar el mecanismo de autorización para comprobar si el usuario autenticado tiene acceso para realizar la acción solicitada en cada función que utilice una entrada de datos del cliente para acceder a un registro de la base de datos.
• Priorizar el uso de valores aleatorios e impredecibles como GUIDs para los identificadores de los registros.
• Incluir test de verificación para evaluar posibles vulnerabilidades del mecanismo de autorización y no incluir los cambios que hagan fallar dichas pruebas.

Desde Tarlogic, también recomendamos aplicar una política de mínimo privilegio por defecto sobre la implementación de los controles de autorización. Asimismo, también es interesante eliminar cualquier parámetro del lado del cliente relacionado con la identidad o los permisos del usuario, ya que esta información debería ser siempre obtenida del lado del servidor en base a la sesión activa.

2.2. Autenticación incorrecta

Los endpoints de autenticación son activos cruciales, por lo que es fundamental protegerlos frente a la actividad maliciosa. OWASP cita diversos escenarios en los que una API es vulnerable con respecto a la autenticación:

• Se permite la introducción de credenciales donde el agresor emplea la fuerza bruta con un listado de nombres de usuario y contraseñas que son válidos.
• Es posible realizar ataques de fuerza bruta sobre la misma cuenta de usuario, sin disponer de un mecanismo de bloqueo de la cuenta.
• Se pueden emplear contraseñas débiles o sin cifrar.
• Se envían datos de autenticación sensibles como tokens o contraseñas en la URL.
• Los usuarios pueden modificar su email o contraseña o realizar operaciones sensibles sin que se les requiera confirmación mediante la introducción de contraseña.
• Se utilizan claves de cifrado débiles
• No se valida la autenticidad de los tokens.
• Acepta tokens JWT sin firmar y/o cifrar.
• No se valida el tiempo de expiración del token JWT.
• Almacenamiento de claves en texto plano, débiles o sin aplicar un hash.
• Uso de claves de cifrado débiles.

El grupo de trabajo de OWASP que confeccionó el Top 10 de seguridad API sostiene que los mecanismos de autenticación son targets sencillos para los actores hostiles, puesto que están expuestos y existen herramientas que facilitan la explotación. Además, OWASP alerta del impacto técnico de esta vulnerabilidad, puesto que, a través de ella, los delincuentes pueden conseguir un control completo de las cuentas de otros usuarios, acceder a sus datos privados y suplantar su identidad para llevar a cabo acciones sensibles.

2.2.1. Prevención

El Top 10 de seguridad API propone una serie de acciones que se pueden implementar para prevenir esta vulnerabilidad:

• Conocer con precisión todos los flujos de autenticación de la API.
• Analizar todos los mecanismos de autenticación.
• Emplear los estándares existentes a la hora de gestionar la autenticación, la generación de tokens y el almacenamiento de contraseñas.
• Los endpoints de recuperación de credenciales y contraseñas olvidadas han de gestionarse como endpoints de inicio de sesión, en lo relativo al uso de fuerza bruta, la limitación de velocidad y las protecciones de bloqueo.
• Exigir doble autenticación para realizar operaciones sensibles.
• Optar por la autenticación multifactor siempre que sea posible.
• Poner en marcha mecanismos contra los ataques de fuerza bruta y la introducción de credenciales.
• Disponer de mecanismos de bloqueo de cuentas para evitar ataques contra los usuarios.
• Realizar comprobaciones de contraseñas débiles.
• Las claves de API solo han de emplearse para la autenticación de los clientes API, y no para la autenticación de usuarios.

2.3. Autorización rota a nivel de propiedad de objeto

El Top 10 de seguridad API de OWASP establece que una API es vulnerable cuando un usuario puede acceder a un objeto empleando un endpoint de la API sin que se haya procedido a validar que dicho usuario tiene derecho a acceder a las propiedades específicas del objetivo a las que quiere acceder.

De tal forma que el endpoint de la API es vulnerable si:

• Expone propiedades de un objeto consideradas sensibles y a las que no debe acceder el usuario.
• Permite al usuario cambiar, añadir y o eliminar el valor de una propiedad sensible, para la que no debería tener acceso.

Muchas API exponen endpoints que devuelven todas las propiedades de los objetos. Además, existen herramientas automatizadas para identificar propiedades que puedan ser manipuladas. La explotación de esta vulnerabilidad puede servir para acceder, robar y corromper datos. Y, en algunos casos, el acceso no autorizado a las propiedades de los objetos puede ser empleado por los actores hostiles para escalar privilegios y tomar el control de la cuenta.

2.3.1. Prevención

Para evitar esta vulnerabilidad, OWASP recomienda:

• Si se expone un objeto utilizando un endpoint de API, verificar siempre si el usuario ha de poder acceder a las propiedades del objeto que se expone.
• Evitar métodos genéricos y seleccionar las propiedades específicas que se desean devolver.
• Evitar usar funciones que vinculen automáticamente los datos del cliente con variables de código, objetos internos o propiedades del objeto.
• Solo permitir cambios en las propiedades del objeto que han de ser actualizadas por el cliente.
• Poner en marcha mecanismos de validación de respuestas.
• Mantener al mínimo las estructuras de datos devueltas, en función de las necesidades y objetivos empresariales.

2.4. Consumo no restringido de recursos

Las API tienen que satisfacer múltiples solicitudes y para ello necesitan emplear recursos como ancho de banda, memoria o almacenamiento. Si no se limita el consumo de recursos, se pueden producir dos escenarios:

• La explotación de esta vulnerabilidad por actores hostiles mediante un ataque de denegación de servicio (DoS), ante la falta de suficientes recursos para atender a todas las peticiones que se realizan a la API.
• Un aumento sustancial de los costes operativos asociado al incremento de los recursos que se deben emplear, por ejemplo, más almacenamiento en la nube.

La explotación de la falta de límites en el consumo de recursos es fácilmente explotable, puesto que solo es necesario realizar peticiones a la API. Los delincuentes tienen a su alcance herramientas automatizadas para realizar ataques DoS a través de altas cargas de tráfico.

El Top 10 de seguridad API de OWASP considera que es fundamental establecer límites adecuados en relación con el tiempo de espera de ejecución, la memoria máxima que se puede asignar, el número máximo de procesos o el tamaño máximo del archivo cargado.

2.4.1. Prevención

Para evitar esta vulnerabilidad de las API, OWASP recomienda:

• Disponer de una solución que limite la memoria, la CPU, el número de reinicios, descriptores de ficheros abiertos y procesos como contenedores, o funciones lambda en infraestructuras serverless.
• Establecer un tamaño máximo de datos en todos los parámetros entrantes. Por ejemplo, el número máximo de elementos en arrays o el tamaño máximo de los archivos de carga.
• Estipular un límite a la frecuencia con la que un cliente puede interactuar con la API.
• Asegurarse de que la limitación de velocidad vaya en consonancia con las necesidades y objetivos empresariales.
• Limitar el número de veces o la frecuencia con la que un único usuario de la API puede ejecutar una única operación.
• Añadir una validación del lado del servidor para los parámetros especialmente relacionados con el número de registros devueltos.
• Configurar límites de gasto para todos los proveedores de servicios o establecer alertas de facturación.

2.5. Autorización rota a nivel de función

El quinto puesto del Top 10 de seguridad API lo ocupa la autorización rota a nivel de función. Para detectar esta clase de problemas, OWASP sostiene que se ha de llevar a cabo un análisis en profundidad del mecanismo de autorización, teniendo en cuenta la jerarquía de los usuarios y los roles y grupos existentes. El objetivo de este análisis es descubrir si:

• Un usuario normal puede acceder a endpoints administrativos.
• A pesar de no tener acceso, un usuario puede realizar acciones sensibles cambiando el método HTTP.
• Un usuario de un determinado grupo puede acceder a una función a la que solo deberían tener acceso los usuarios de otro grupo, porque ha sido capaz de adivinar la URL del endpoint y los parámetros.

Mediante la explotación de esta vulnerabilidad, los actores hostiles pueden acceder a funciones no autorizadas, en especial, a las funciones administrativas. Más allá de la exfiltración, eliminación y corrupción de los datos, los agresores pueden llegar a interrumpir el servicio, lo que conllevaría graves consecuencias económicas.

2.5.1. Prevención

El Top 10 de seguridad API de OWASP hace hincapié en que la mejor forma para evitar esta vulnerabilidad es contando con un módulo de autorización consistente y fácilmente analizable. El mecanismo de autorización debe denegar el acceso por defecto y realizar concesiones explícitas a usuarios específicos para acceder a cada función.

Asimismo, este documento recomienda revisar los endpoints de API para detectar defectos de autorización a nivel de función, teniendo en cuenta siempre los objetivos de negocio. También resulta fundamental asegurarse de que:

• Todos los controladores administrativos realicen comprobaciones de autorización basadas en el grupo y rol de cada usuario.
• Las funciones administrativas dentro de un controlador normal también implementen comprobaciones de autorización basadas en el grupo y rol de los usuarios.

2.6. Acceso sin restricciones a flujos empresariales sensibles

OWASP señala que cuando se crea un endpoint de API, se expone un flujo de negocio y es fundamental entender que hay flujos de negocio más sensibles que otros y el acceso excesivo a ellos puede resultar perjudicial para la empresa.

¿De qué flujos de negocio estamos hablando? Ejemplos de estos flujos pueden ser los de compra de un producto, el de publicación de comentarios o el de reservas.

¿Cuándo se considera que el endpoint de API es vulnerable? Cuando expone un flujo de negocio sensible sin contar con mecanismos que restrinjan el acceso de forma adecuada.

Los actores hostiles han de comprender el modelo de negocio respaldado por la API para buscar los flujos de negocio más sensibles e intentar acceder a ellos para dañar la actividad empresarial.

El impacto de la explotación de esta vulnerabilidad no es técnico, pero puede ser muy perjudicial para la empresa, afectando a su actividad, por ejemplo, impidiendo a los consumidores legítimos comprar un producto o realizar una reserva porque un atacante haya podido agotar el stock mediante un proceso automático.

2.6.1. Prevención

La mitigación de esta vulnerabilidad debe acometerse tanto desde el punto de vista del negocio, como en lo relacionado a la ingeniería, para proteger los flujos empresariales y subsanar las debilidades.

OWASP recomienda para hacer frente con éxito a las amenazas automatizadas:

• Implementar la huella digital de dispositivos. Denegar el servicio a dispositivos cliente inesperados.
• Mejorar la detección humana, empleando captchas o biometría.
• Detectar patrones no humanos estudiando el flujo de los usuarios.
• Bloquear direcciones IP de nodos de salida de Tor y proxies conocidos.
• Proteger y limitar el acceso a las API que consumen directamente las máquinas.

2.7. Falsificación de peticiones del lado del servidor

El documento de OWASP señala que los problemas de falsificación de peticiones del lado del servidor tienen lugar cuando una API conecta a un recurso remoto sin validar la URL que proporciona el usuario. De esta forma, el actor hostil coacciona a la aplicación para que esta envíe una solicitud manipulada a un destino inesperado.

Para explotar esta vulnerabilidad, los atacantes deben encontrar un endpoint de API que acceda a una URL proporcionada por el cliente. ¿Qué se logra mediante la explotación? Se puede conseguir una enumeración de servicios internos, obtener información, o eludir cortafuegos y otros mecanismos de seguridad, ya que el atacante se aprovecha de la posición privilegiada del servidor en la infraestructura para forzar peticiones arbitrarias.

El Top 10 de seguridad API alerta, además, de que en algunos casos la explotación de esta vulnerabilidad puede permitir lanzar ataques DoS o abrir la puerta a que el servidor sea empleado como proxy de cara a ocultar otras actuaciones maliciosas.

2.7.1. Prevención

De cara a evitar esta clase de problemas, OWASP recomienda:

• Aislar el mecanismo de obtención de recursos en la red.
• Establecer listas de permitidos:
  • Orígenes remotos de los que los usuarios pueden descargarse recursos.
  • Esquemas de URL y puertos.
  • Medios que son aceptados para una funcionalidad concreta.
• Desactivar las redirecciones HTTP.
• Utilizar un analizador de URL para evitar incoherencias en su análisis.
• Validar y sanear los datos de entrada que proporcionan los clientes.
• No enviar respuestas sin procesar.

2.8. Incorrecta configuración de la seguridad

¿Qué significa que una API presente una incorrecta configuración de seguridad? Según el Top 10 de seguridad API de OWASP esta situación se produce cuando:

• La API no está correctamente securizada en toda su pila o existen permisos mal configurados en los servicios en la nube.
• Faltan los últimos parches de seguridad o los sistemas están obsoletos.
• Se activan funciones innecesarias.
• Se registran discrepancias en la forma en que los servidores procesan las solicitudes entrantes en la cadena de servidores HTTP.
• Falta la Transport Layer Security (TLS).
• No se procede a enviar las directivas de seguridad o control de caché a los clientes de la API.
• Bien no existe una política de uso compartido de recursos de origen cruzado o dicha política no se ha configurado de la forma adecuada.
• Los mensajes de error exponen información sensible.

OWASP alerta de que los ciberdelincuentes intentan aprovecharse de todos estos fallos que no han sido subsanados. Además, los problemas de configuración de la seguridad pueden producirse en cualquier nivel de la API y no solo pueden ser explotados para exponer datos sensibles sobre los usuarios de un software, sino que los actores hostiles pueden llegar a comprometer el servidor.

2.8.1. Prevención

Para prevenir problemas relacionados con una mala configuración de la seguridad de una API es fundamental protegerla a lo largo de su ciclo de vida:

• Poner en marcha un proceso de hardening en el ciclo de vida del despliegue, que sirva para aplicar un entorno debidamente blindado.
• Revisar y actualizar las configuraciones de la API, incluyendo archivos de orquestación, componentes y servicios en la nube.
• Automatizar la evaluación de la configuración y los ajustes en todos los entornos, para que dicho análisis pueda realizarse de forma continua.

2.9. Gestión inadecuada del inventario

El penúltimo puesto del Top 10 de seguridad API lo ocupa la gestión del inventario. Las empresas no solo tienen que conocer a la precisión sus propias API, sino que también deben saber cómo las API almacenan datos de terceros o comparten información con ellos. De lo contrario se pueden encontrar con dos tipos de puntos ciegos:

• Punto ciego de documentación. No se sabe, por ejemplo, en qué entorno se ejecuta una API o qué versión se está ejecutando, ni se dispone de un inventario del host, o el que existe está desactualizado.
• Punto ciego de flujo de datos. La API comparte datos sensibles con un tercero sin justificación o aprobación empresarial. No existe un inventario del flujo de datos o no se puede visualizar de forma profunda qué datos sensibles se comparten.

Inventariar los flujos de datos sensibles es esencial a la hora de responder ante un incidente cuando este se produce del lado de un tercero.

2.9.1. Prevención

El Top 10 de seguridad API de OWASP recomienda a las organizaciones:

• Realizar un inventario de todos los hosts de API, detallando el entorno de la API, la versión y quién tiene acceso de red al host.
• Inventariar los servicios integrados, indicando su función en el sistema, su flujo de datos y su nivel de sensibilidad.
• Documentar todos los aspectos de la API: autenticación, errores, redirecciones, límite de velocidad…
• Automatizar la generación de documentación mediante el uso de estándares.
• La documentación ha de estar a disposición de las personas autorizadas para usarla.
• Contar con servicios de ciberseguridad para proteger todas las versiones expuestas de una API.
• No emplear datos de producción con despliegues de API que no son de producción.
• Si se incorporan mejoras de seguridad a las nuevas versiones de una API, se debe realizar un análisis de riesgos e informar de las medidas que se deben tomar con respecto a las versiones anteriores. Estableciendo si se pueden implementar estas medidas o si, en cambio, los clientes deben dar el salto a la última versión.

2.10. Consumo inseguro de API

Muchos desarrolladores tienden a confiar en las API de terceros, sobre todo si los proveedores son empresas conocidas y avaladas por su trayectoria. Esto se traduce en que las normas de seguridad que adoptan son más débiles en aspectos clave como la autenticación, la autorización la seguridad del transporte o la validación de las entradas. Este punto está relacionado con la gestión de la seguridad en la cadena de suministro (supply chain).

La vulnerabilidad de consumo inseguro de API se manifiesta cuando:

• Una API interactúa con otras a través de un canal no cifrado.
• No se validan ni sanean los datos obtenidos de otras API antes de procesarlos y trasladarlos a componentes de la API.
• Se siguen ciegamente las redirecciones.
• No se limitan los recursos que se pueden emplear para procesar respuestas de servicios de terceros.
• No se implementan tiempos de espera en las interacciones con servicios de terceros.

OWASP hace hincapié en que, para poder explotar esta vulnerabilidad, los actores hostiles necesitan saber con qué API está integrada la API objetivo e, incluso, comprometerlas. Si la explotación es exitosa, los delincuentes pueden obtener información sensible y ejecutar ataques de inyección y DoS.

2.10.1. Prevención

El ranking de OWASP plantea tres acciones para evitar los problemas ligados a un consumo inseguro de otras API:

• Tener en cuenta la estrategia de seguridad con respecto a las API de los proveedores de servicios.
• Tomar las medidas necesarias para que las interacciones de la API se lleven a cabo a través de un canal de comunicación seguro (TLS). Antes de emplear los datos que se reciben a través de otras API es necesario validarlos y sanearlos.
• No seguir ciegamente las redirecciones, para ello se ha de contar con una lista de ubicaciones conocidas a las que las API integradas pueden redirigir a la API de la organización.

3. El Top 10 de seguridad API evidencia la importancia de las auditorías de seguridad

A lo largo del apartado anterior no solo listamos las principales vulnerabilidades a las que tienen que hacer frente los desarrolladores y las organizaciones que disponen de API, sino que también hicimos referencia a las medidas que se pueden poner en marcha para fortalecer estos activos críticos de una infraestructura IT.

Todas las medidas recogidas en el Top 10 de seguridad API de OWASP ponen en valor la importancia de que las organizaciones realicen auditorías de seguridad web que analicen de forma continua las API para identificar vulnerabilidades y mitigarlas antes de que sean explotadas por actores hostiles y se produzcan incidentes de seguridad.

La auditoría de seguridad web que prestan los profesionales de Tarlogic Security sirve para:

• Identificar vulnerabilidades relacionadas con la infraestructura de los servidores web.
• Detectar vulnerabilidades de aplicación, procediendo a verificar toda clase de inyecciones y técnicas sobre sus puntos de entrada.
• Realizar pruebas de seguridad específicas para múltiples tipos de activos, entre los que ocupan un lugar preponderante las API.
• Identificar vulnerabilidades relacionadas con el uso de software, así como con la lógica de negocio de la aplicación.

En definitiva, las API han revolucionado el desarrollo de aplicaciones, reduciendo los plazos, abaratando los costes y facilitando la producción de software escalable y flexible. De ahí que ocupen, en la actualidad, un papel central en la digitalización de la vida de las personas y las empresas.

Precisamente, esta centralidad las ha situado como un target prioritario para muchos grupos de ciberdelincuentes. De ahí que iniciativas como el Top 10 de seguridad API de OWASP busquen contribuir a un ecosistema de API más seguro, dificultando las acciones de los actores hostiles y logrando proteger a las empresas y sus clientes.