¿Qué es la seguridad de las API?

La seguridad de las API es la práctica de proteger la interfaz de programación de aplicaciones (API) de ataques que utilizarían o intentarían explotar maliciosamente una API para robar datos confidenciales o interrumpir servicios. La seguridad de las API emplea estrategias, técnicas y soluciones para garantizar que sólo los usuarios autorizados puedan acceder a una API y utilizarla, y que los datos transmitidos a través de la API estén protegidos de accesos o manipulaciones no autorizados.

 

Explicación de la seguridad de la API

Dado que las API funcionan como el marco de backend de sistemas y servicios, es fundamental asegurarlas para proteger los datos sensibles que transfieren, incluida la información de acceso, como la autenticación, la autorización, la validación de entradas y el cifrado. La seguridad de las API se refiere a los métodos y herramientas diseñados para proteger estos marcos backend y mitigar los ataques de violaciones de acceso, ataques de bots y abusos.

Tipos comunes de ataques a la API

  • Ataque de denegación de servicio (DoS)
  • Ataque distribuido de denegación de servicio (DDoS)
  • Ataque Man-in-the-middle (MITM)
  • Ataque de control de acceso roto
  • Inyección

Un ataque a la API con éxito puede provocar pérdidas masivas de datos, el robo de información privada o personal y la interrupción del servicio.

 

Definición de una API

API son las siglas en inglés de interfaz de programación de aplicaciones, que consiste en un conjunto de definiciones y protocolos que permite que los componentes de software se comuniquen. Al servir de intermediario entre los sistemas de software, la API permite a las aplicaciones o servicios de software compartir datos y funcionalidades. Pero la API hace algo más que proporcionar una infraestructura de conectividad. También rige cómo se permite que las aplicaciones de software se comuniquen e interactúen. La API controla los tipos de solicitudes que intercambian los programas, cómo se realizan las solicitudes y qué formatos de datos están permitidos.

Las API permiten a las organizaciones compartir datos con clientes y otros usuarios externos. Entre los tipos de API se incluyen las utilizadas para el procesamiento de pagos, las videoconferencias, las redes sociales, los mensajes de texto, la monitorización médica o del estado físico y los hogares inteligentes. Las API pueden ser abiertas o cerradas, públicas o privadas, y suelen ajustarse a estándares arquitectónicos, como REST, SOAP o GraphQL.

Las API también benefician a los desarrolladores al darles acceso a la funcionalidad de otras aplicaciones, aliviando la necesidad de construir repetidamente una nueva infraestructura de conectividad o incluso de comprender su código o arquitectura subyacentes.

Figura 1: Estructura moderna de la aplicación
Figura 1: Estructura moderna de la aplicación

 

Por qué es importante la seguridad de las API

Las aplicaciones son omnipresentes, una parte integral de los negocios y la sociedad. Y detrás de casi todas las aplicaciones hay una API, lo que eleva la seguridad de las API a misión crítica.

Las API sirven como marco de trabajo backend para la mayoría de las aplicaciones nativas de la nube, incluidas las aplicaciones móviles, las aplicaciones web y SaaS, así como las aplicaciones internas, de cara a los socios y de cara al cliente. Para poner el uso de las API en perspectiva, Postman, la plataforma de administración de API, vio 1.130 millones de llamadas a API en 2022. Con el auge de las API, por supuesto, llega una superficie de ataque potencialmente lucrativa que atrae a los malos actores.

Dado que las API exponen la lógica de las aplicaciones, los recursos y los datos sensibles -incluida la información personal identificable (IPI)-, se han convertido en un objetivo para los atacantes. Si los atacantes son capaces de acceder a API desprotegidas, pueden interrumpir el negocio, acceder o destruir datos sensibles y robar bienes.

Figura 2: Aplicación moderna de microservicios que aprovecha las API
Figura 2: Aplicación moderna de microservicios que aprovecha las API

 

Enfoque tradicional de la seguridad de las aplicaciones web

La seguridad de las aplicaciones web en la era de las aplicaciones monolito consistía en implementar un web application firewall (WAF) en el perímetro para interceptar e inspeccionar el tráfico HTTP enviado por los clientes web. Los WAF proporcionaban, y siguen proporcionando, una seguridad eficaz de las aplicaciones cuando el riesgo potencial para la aplicación implica principalmente entradas de usuario maliciosas incrustadas en envíos de formularios web HTTP estándar o peticiones del navegador.

Pero la naturaleza de las aplicaciones web ha cambiado de aplicaciones monolíticas alojadas en servidores web individuales a aplicaciones en contenedores, nativas de la nube, distribuidas en un clúster de servidores anfitriones.

Los desarrolladores y los equipos de seguridad actuales -que trabajan con una arquitectura de microservicios altamente distribuida y nativa de la nube- deben enfrentarse a redes sin perímetro. Las aplicaciones modernas consumen datos de una amplia gama de fuentes: solicitudes web estándar, llamadas a la API de dispositivos móviles, eventos en la nube, comunicación telemétrica de dispositivos IoT, almacenamiento en la nube, etc.

Las peticiones HTTP entrantes de los clientes (es decir, el tráfico norte-sur) suelen ser las primeras de una secuencia de flujos de comunicación. En muchos casos, una sola solicitud entrante genera docenas de llamadas a la API interna (es decir, tráfico este-oeste). Si esas llamadas internas a la API no se inspeccionan y validan adecuadamente, los endpoints de la API quedan desprotegidos.

Inspeccionar la entrada en el perímetro no es suficiente para detectar cargas peligrosas. Los endpoints internos de la API pueden estar mal configurados y permitir el acceso no autorizado a microservicios individuales, exponiendo la lógica de la aplicación a acciones maliciosas. Es fundamental que todos los endpoints de las API, externos e internos, estén continuamente vigilados y protegidos.


Vídeo: Visión general de la seguridad de las API y consejos para mejorarla

 

Anatomía de un ataque a la API

A medida que las organizaciones dependen de las API para impulsar sus negocios, los atacantes están a la caza de fallos en las API que puedan explotar. Este ejemplo de ataque a una API dirigido a una aplicación de comercio electrónico con una aplicación móvil como frontend ilustra lo fácil que es para los actores de amenazas encontrar vías de acceso a datos valiosos.

Figura 3: La anatomía de un ataque basado en API
Figura 3: La anatomía de un ataque basado en API

Paso 1: Mediante ingeniería inversa de la aplicación móvil, un atacante descubre una URL de endpoint de API obsoleta utilizada para recuperar datos de un microservicio backend.

Paso 2: El atacante se da cuenta de que no se requiere ni autenticación ni autorización para enviar llamadas API a este endpoint.

Paso 3: El atacante abusa de la vulnerabilidad SQLi. La URL del endpoint de la API proporciona un identificador de producto único en forma de valor numérico, y el atacante ejecuta una serie de comprobaciones automatizadas para descubrir que el campo de entrada puede aprovecharse para llevar a cabo un ataque SQLi con éxito.

Paso 4: En lugar de abusar de este SQLi para manipular los datos, el atacante opta por abusar de la vulnerabilidad SQLi y ejecuta un comando shell en el microservicio que ejecuta la base de datos SQL. El comando shell descarga un ejecutable malicioso y lo ejecuta. El ejecutable es un software de minería de bitcoin.

 

Riesgos de seguridad de la API

Los errores de configuración de la API, los fallos lógicos y las vulnerabilidades dejan las aplicaciones y los datos expuestos a los atacantes. Aunque una puerta de enlace de API sólo puede ver el tráfico de API enrutado a través de la puerta de enlace y no ofrece visibilidad al tráfico interno, algunas organizaciones relegan su seguridad de API a una puerta de enlace de API, creyendo que proporciona una protección completa de API.

Los equipos de seguridad necesitan visibilidad en toda su superficie de API. No se puede proteger lo que no se ve - y lo que no se ve se convierte en última instancia en la actividad no detectada de los malos actores que descubren una API en la sombra.

Aunque las puertas de enlace de API supervisan eficazmente las API y su uso, son incapaces de detectar y bloquear los ataques. La seguridad de las API requiere protección en tiempo real contra ataques maliciosos, además de visibilidad y administración de riesgos.

El Top 10 de OWASP

El Open Web Application Security Project (OWASP) publicó en 2019 una lista de los 10 principales riesgos de seguridad de las API para concienciar sobre los riesgos de seguridad de las API que afectan a las aplicaciones web modernas. Esta lista esboza los ataques más comunes contra las API web e incluye consejos para proteger sus API de estas amenazas.

Autorización a nivel de objeto rota

Los endpoints que manejan identificadores de objetos suelen estar expuestos por API, lo que da lugar a un problema de control de acceso a nivel que amplía la superficie de ataque. Si no se implementan las comprobaciones de autorización adecuadas, por ejemplo, los atacantes podrían sustituir el ID de un recurso que pertenece a otro usuario durante una llamada a la API. Conocido como ataque de referencia directa a objeto inseguro (IDOR), permite al atacante acceder a un recurso para el que no estaba autorizado.

Autenticación de usuario rota

Los mecanismos de autenticación de las API son blancos fáciles porque están expuestos a todo el mundo. Un mecanismo de autenticación mal implementado, lo que se conoce como una vulnerabilidad de autenticación de API rota, da entrada a atacantes que pueden explotar fallos de implementación para asumir la identidad de usuarios autorizados.

Los errores de configuración de la autenticación de la API pueden producirse cuando se pasan por alto las mejores prácticas del sector, como en el caso de no implementar la validación del token de acceso o almacenar credenciales y claves en las URL de los endpoints de la API.

Exposición excesiva de datos

Cuantos más datos estén expuestos, mayor será el riesgo. Durante la implementación de la API, los desarrolladores a veces exponen las propiedades de los objetos sin restricciones detalladas y confían en que el cliente filtre los datos innecesarios antes de que se muestren en la interfaz de usuario. Pero incluso si el cliente de la API filtra los datos sensibles, los atacantes pueden aprovecharse de la llamada inicial a la API y tal vez acceder a números de tarjetas de crédito, credenciales de inicio de sesión y números de la Seguridad Social.

Falta de recursos y limitación de tarifas

Las API que no restringen el número de recursos a los que puede llamar un cliente son vulnerables al abuso de las API a través de la sobrecarga de tráfico. Este tipo de sobrecarga degrada el rendimiento del servidor API, bloqueando a los usuarios legítimos y pudiendo provocar una DoS. La sobrecarga del servidor API también expone la API a fallos de autenticación, como la fuerza bruta.

Autorización a nivel de función rota

Uno de los retos a los que se enfrentan los desarrolladores de API es la complejidad de la implementación de políticas de control de acceso para diferentes jerarquías de grupos de usuarios y roles. La nebulosa distinción entre las funciones de administración y las normales crea fallos de autorización que los atacantes pueden explotar para obtener acceso a los recursos de un usuario o realizar funciones administrativas no autorizadas.

Asignación masiva

Una vulnerabilidad de asignación masiva surge cuando los datos suministrados por el cliente se vinculan a modelos de datos sin ser filtrados contra una lista blanca que impediría a los usuarios asignar datos a campos protegidos. Con esta vulnerabilidad, los atacantes pueden obtener acceso a datos sensibles interceptando las consultas de la API y cambiando las propiedades de los objetos backend almacenados adivinando las propiedades de los objetos, leyendo la documentación y rastreando los endpoints de la API en busca de pistas sobre cómo comprometer los atributos de los datos de una API privada.

Errores de configuración de seguridad

Los errores de configuración de la seguridad pueden exponer información confidencial de los usuarios y detalles del sistema, lo que puede poner en peligro el servidor. Entre las causas más comunes se encuentran la compartición permisiva de recursos entre orígenes (CORS), las configuraciones incompletas o ad hoc, las cabeceras HTTP o los métodos HTTP incorrectos, las configuraciones predeterminadas inseguras, las configuraciones incompletas o incorrectas y los mensajes de error verbose que exponen información sensible.

Inyección

Las API están sujetas a vulnerabilidades de inyección -inyección de SQL, inyección NoSQL e inyección de comandos- que pueden producirse cuando se envían datos no fiables a un intérprete como parte de un comando o consulta. Un atacante puede engañar a un intérprete para que ejecute comandos peligrosos, exponiendo datos no autorizados para su manipulación y robo.

Administración inadecuada de los activos

Las API exponen más endpoints que las aplicaciones web tradicionales, y una administración sólida de las API que haga un seguimiento de estos endpoints es esencial para evitar el abuso de los endpoints sensibles o vulnerables expuestos. Los endpoints de API obsoletos o los endpoints de depuración, por ejemplo, podrían ser utilizados por los atacantes para comprometer la aplicación.

Registro y supervisión insuficientes

Un registro y una supervisión inadecuados, aunque no son una amenaza directa, retrasan la detección de actividades maliciosas. Los malos actores trabajan bajo el manto de la oscuridad con tiempo de sobra para avanzar en los ataques y progresar hacia diferentes sistemas para alterar, extraer y destruir datos. La detección de la amenaza persistente puede tardar más de 200 días, según los estudios sobre infracciones. Y tras una violación de datos, sin un registro y una supervisión adecuados, las organizaciones carecen de la información forense necesaria para evaluar los daños.


Vídeo: Conozca OWASP, AppSec y los 10 principales riesgos para la seguridad de las aplicaciones de OWASP

 

Seguridad de API para SOAP, REST y GraphQL

SOAP, REST y GraphQL son tres patrones comunes de arquitectura de API, y cada estilo arquitectónico de API presenta consideraciones de seguridad distintas.

Seguridad de la API SOAP

SOAP (protocolo simple de acceso a objetos) es un protocolo para el intercambio de datos estructurados en la implementación de servicios web en redes informáticas. SOAP utiliza XML como formato de mensaje y puede transportarse a través de diversos protocolos de nivel inferior, como HTTP y SMTP. Las API SOAP suelen estar protegidas mediante una combinación de seguridad de la capa de transporte (como HTTPS) y seguridad a nivel de mensaje (como firmas digitales XML y cifrado).

La seguridad de la API SOAP implica extensiones del protocolo para tratar los problemas de seguridad. SOAP se adhiere a las especificaciones de los servicios web (WS), que garantizan la seguridad a nivel empresarial de todos los servicios web a través de características como WS-ReliableMessaging, que amplía el soporte incorporado para la gestión de errores.

Seguridad de la API de Rest

La arquitectura de las API de transferencia de estado representacional, o API REST, se basa en la transferencia de datos JSON y en el protocolo de transferencia HTTP/S, que simplifican el desarrollo de las API REST en comparación con otras arquitecturas de API. Las API RESTful utilizan peticiones HTTP para POST (crear), PUT (actualizar), GET (leer) y DELETE (borrar) datos.

Al carecer de disposiciones de seguridad integradas, la seguridad de la API de Rest depende del diseño de la API. Los servicios de transmisión de datos, implementación e interacción con el cliente deben incorporar consideraciones de seguridad. La mayoría de las API RESTful se basarán en la seguridad de la capa de transporte (como HTTPS) y la autenticación basada en tokens.

Una opción arquitectónica común para abordar la seguridad de las API REST es implementarlas detrás de una puerta de enlace de API y, a continuación, ofrecer esta opción de conectividad a los clientes. Sin embargo, una puerta de enlace API no está equipada para defenderse de toda la gama de amenazas a la seguridad.

REST frente a SOAP

Las API SOAP y RESTful admiten solicitudes y respuestas HTTP, así como la capa de sockets seguros (SSL), pero los puntos en común acaban ahí. Las API SOAP, con funciones de seguridad incorporadas, son intrínsecamente seguras. Por el contrario, las API RESTful deben hacerse seguras mediante opciones de implementación y arquitectura.

Seguridad de la API GraphQL

GraphQL es un lenguaje API de código abierto que describe la forma en que los clientes solicitan información y actúa como tiempo de ejecución para realizar consultas con los datos existentes. La sintaxis GraphQL es utilizada por los desarrolladores para realizar solicitudes de datos específicos de una o varias fuentes. Con GraphQL, los clientes pueden definir la estructura de datos para una solicitud, y el servidor se asegurará de que se devuelva la estructura exacta.

Hacer cumplir la seguridad de la API GraphQL plantea retos relacionados con las solicitudes personalizables y flexibles. El servidor puede no ser capaz de manejar consultas complejas y podría ejecutar inadvertidamente consultas maliciosas en el proceso.

Los métodos para mitigar los riesgos de seguridad de la API GraphQL incluyen el estrangulamiento y el establecimiento de una profundidad máxima de consulta, así como un tiempo de espera de consulta para defenderse de las consultas de gran tamaño.

 

Mejores prácticas de seguridad de la API

Con las API cada vez más a disposición del público, es importante abordar los riesgos de exposición de los datos mediante la implementación de las mejores prácticas para minimizar la superficie de ataque, remediar las vulnerabilidades y detener las actividades maliciosas en tiempo casi real.

Utilice métodos seguros de autenticación y autorización

Asegúrese de que sólo los usuarios autorizados puedan acceder a la API con métodos de autenticación seguros, como OAuth2 o tokens web JSON (JWT).

Implementación de la limitación de velocidad

Implemente la limitación de velocidad en sus API para evitar ataques de fuerza bruta y otros comportamientos maliciosos. La limitación de la tasa restringe el número de solicitudes que se pueden realizar a una API en un periodo determinado.

Utilizar HTTPS

Las solicitudes y respuestas a la API deben realizarse utilizando HTTPS para garantizar que están encriptadas y son seguras. Esto es especialmente crítico cuando se trata de datos sensibles.

Realice evaluaciones de seguridad periódicas

Evalúe periódicamente la seguridad de sus API para identificar posibles vulnerabilidades. Revise los cambios en el inventario de API para detectar las nuevas API expuestas y sus perfiles de riesgo, incluida la exposición a datos sensibles, la exposición a Internet, las vulnerabilidades de carga de trabajo y el nivel de autenticación.

Utilizar una clave API

Una clave API es un identificador único utilizado para identificar la aplicación que llama a una API y verificar la autorización de acceso. Las claves API difieren de los tokens de autenticación en que identifican a la aplicación (o sitio web) que realiza la llamada a la API, en lugar de a la persona que utiliza la aplicación (o sitio web). Ambas son medidas de seguridad importantes.

Siga las mejores prácticas de almacenamiento de claves API para evitar llamadas no deseadas, accesos no autorizados y una posible violación de datos con pérdida de información personal.

Supervise sus API

Administre y supervise las especificaciones de la API, la documentación, los casos de prueba, el tráfico y las métricas. Bloquee la actividad no deseada, como el tráfico API malicioso y los bots maliciosos, para ayudar a proteger la aplicación y reducir costos innecesarios.

Eduque a los equipos sobre las mejores prácticas de seguridad

Incorpore la seguridad en una fase temprana del proceso CI/CD y ofrezca capacitación para mejorar los conocimientos de sus desarrolladores sobre los riesgos de seguridad, como la autenticación débil y las vulnerabilidades lógicas. Implemente los principios de DevSecOps , incluida la colaboración entre los equipos de seguridad y desarrollo.

Conozca sus vulnerabilidades

Identifique los puntos débiles en el ciclo de vida de su API buscando de forma rutinaria los 10 principales riesgos para la seguridad de las API de OWASP. Utilice herramientas y técnicas de escaneado de API para identificar cada vulnerabilidad de la API y resuélvala inmediatamente para evitar su explotación.

Requerir un token de seguridad para la autenticación

Exigir un token de seguridad para la autenticación es una primera línea de defensa. Los tokens de seguridad protegen las API de accesos no autorizados rechazando la llamada a la API si el token de un usuario no pasa la verificación.

Las mejores prácticas, en resumen, deben comenzar con la visibilidad y la supervisión de sus superficies de ataque, que pueden autodescubrir todas las aplicaciones web y los endpoints API de su entorno. Las capas de defensa deben incluir políticas para el tráfico norte-sur y este-oeste para bloquear las amenazas maliciosas, tanto si se originan en Internet como dentro de sus aplicaciones.

La adición de otra capa de exploración de vulnerabilidades y cumplimiento, junto con una autenticación fuerte, protegerá aún más sus aplicaciones. También tendrá que asegurar sus cargas de trabajo o la capa de infraestructura, como los hosts, las máquinas virtuales, los contenedores y las funciones sin servidor que ayudan a alojar sus aplicaciones.

 

Solución de seguridad API de Prisma Cloud

Prisma Cloud proporciona un completo descubrimiento de API, perfiles de riesgo y protección en tiempo real para todas las API como parte de su completa plataforma de protección de aplicaciones nativas de la nube (CNAPP).

Capacidades de seguridad de la API

  • Descubrimiento de API: Descubra automáticamente todas las API de su entorno y elimine los puntos ciegos causados por API ocultas o no autorizadas.
  • API Perfiles de riesgo: Identifique los riesgos de la API y los factores de riesgo (como la mala configuración, la exposición a datos confidenciales y el control de acceso), y priorice la corrección.
  • Protección en tiempo real: Aplique protecciones en tiempo real contra ataques a través de OWASP Top 10 para APIs, limitación de velocidad y bots maliciosos.

 

Preguntas frecuentes sobre la seguridad de la API

Una aplicación monolítica se construye como una sola unidad, independiente de otras aplicaciones informáticas, con la mayor parte o toda su funcionalidad en un proceso o contenedor. Los programas de software se diseñaban tradicionalmente como aplicaciones monolíticas e incluían todos los componentes necesarios en capas dentro de la aplicación de software: API, servicios, acceso a datos, bases de datos, etc. Diseñadas como tales, las apps monolíticas realizan todas las funciones necesarias para completar una tarea, desde la adquisición de la entrada del usuario hasta el procesamiento y almacenamiento de los datos en una base de datos.
La arquitectura orientada a servicios hace referencia a un diseño de software en el que los componentes de la aplicación proporcionan servicios o intercambios de datos a otros componentes mediante un protocolo de comunicación transmitido a través de una red.

La arquitectura de microservicios consiste en construir aplicaciones dividiendo su funcionalidad en componentes modulares. Las aplicaciones se construyen a partir de microservicios débilmente acoplados que se comunican a través de protocolos ligeros.

Los microservicios libremente acoplados permiten a los desarrolladores crear aplicaciones complejas con rapidez y relativa facilidad. Este tipo de arquitectura nativa de la nube también puede seguir el ritmo de la evolución de las necesidades de los clientes, ya que la naturaleza de desacoplamiento de los microservicios permite a los desarrolladores introducir nuevo código y funcionalidad con más frecuencia de lo que podrían hacerlo de otro modo.

SOAP es un método de intercambio de información entre aplicaciones que utiliza un protocolo ligero basado en XML. Aunque normalmente se transmiten a través de una sesión HTTP, los mensajes SOAP pueden enviarse como lo requiera una aplicación, siempre que el cliente y el servidor utilicen el mismo método.
La seguridad de capa de transporte (TLS) es un protocolo de cifrado que protege las comunicaciones entre redes informáticas e Internet. Ejemplos comunes de TLS en uso incluyen HTTPS, correo electrónico y mensajes de texto. TLS sustituyó a SSL (capa de sockets seguros).
Un endpoint de API es el único recurso accesible de una API. Cuando una API interactúa con otro sistema, los endpoints de la API son los puntos de contacto de la comunicación. Estos puntos de contacto, o endpoints, son el lugar desde el que la API accede a los recursos necesarios para llevar a cabo su función. Dado que los endpoints de las API hacen que los sistemas sean vulnerables a los ataques, es vital prevenir el uso indebido mediante la supervisión de las API.

Mejor integradas en el Ducto de DevOps, las pruebas de seguridad de las API son una práctica que pone a prueba la seguridad de los endpoints de una API para verificar el cumplimiento de las mejores prácticas de seguridad. Para evaluar la autenticación, el cifrado o las condiciones de acceso de los usuarios, por ejemplo, se somete a la API a desafíos de entrada deliberados diseñados para emular los vectores de ataque de los malos actores con el fin de sacar a la luz comportamientos indefinidos, fallos y otras vulnerabilidades. Los hallazgos de las pruebas de la API podrían incluir derivaciones de autorización o autenticación, errores de configuración de seguridad, inyecciones de comandos SQL y OS, y vulnerabilidades de código abierto.

Las pruebas de seguridad de la API pueden implicar pruebas de seguridad dinámicas o estáticas, así como análisis de la composición del software (SCA). SCA coteja el código de una aplicación con las bases de datos CVE. Cuando se identifican los problemas, la herramienta SCA alerta a los desarrolladores de que la aplicación o API utiliza una biblioteca o marco con una vulnerabilidad conocida. Dado el uso generalizado del código abierto en el desarrollo de API, el análisis de la composición del software desempeña un papel fundamental en las pruebas de seguridad de API y aplicaciones.

Una puerta de enlace API es una herramienta que se sitúa entre una aplicación y un conjunto de servicios backend, actuando como proxy inverso para aceptar llamadas API. La puerta de enlace de la API divide cada llamada en varias solicitudes y las dirige a los servicios apropiados, cada uno de los cuales produce una respuesta mientras la puerta de enlace de la API rastrea toda la actividad.
Una API en la sombra, también llamada API zombi, es una API clandestina, no documentada y sin seguimiento. Los promotores a menudo desconocen su presencia y sus cualidades.
Una API abierta, también llamada API pública, es una interfaz de programación de aplicaciones a disposición del público que proporciona a los desarrolladores acceso a una aplicación de software o a un servicio web.
Una API privada es una interfaz de programación de aplicaciones que tiene su aplicación alojada en una organización para servir de interfaz frontend a los datos backend y a las funciones de la aplicación. La interfaz proporciona un punto de entrada para los empleados y contratistas autorizados que trabajan para desarrollar esas funciones.
La inyección de DLL es un tipo de ataque que explota procesos y servicios del sistema operativo Windows. Al sustituir un archivo DLL necesario por una versión infectada y colocarlo dentro de los parámetros de búsqueda de una aplicación, el archivo infectado será invocado cuando se cargue la aplicación, activando sus operaciones maliciosas.

Un webhook es una función de devolución de llamada basada en HTTP que permite la interacción basada en eventos entre dos API, lo que permite a las aplicaciones web recibir pequeñas cantidades de datos de otras aplicaciones. Pero los webhooks no son API. A menudo se denominan API inversas o push porque los webhooks hacen que el servidor envíe al cliente una solicitud HTTP POST una vez que los datos están disponibles (en lugar de recibir y responder a una solicitud HTTP). Las aplicaciones deben disponer de una API para utilizar un webhook.

En entornos GitOps, los webhooks pueden desencadenar flujos de trabajo de automatización y reducir el número de pasos necesarios para implementar canalizaciones de implementación de Git-heavy, incluido el lanzamiento automático de flujos de trabajo de infraestructura como código .