Las medidas de seguridad adecuadas son uno de los aspectos más importantes de la construcción de una interfaz de programación de aplicaciones o API. Es genial para una API conectar sistemas y brindarles a los desarrolladores acceso a los datos y funciones que necesitan para crear nuevas aplicaciones y experiencias digitales, pero solo si esas conexiones y ese acceso están protegidos.
Para el proveedor de API, esto requiere un equilibrio. Uno de los propósitos principales de una API es ayudar a los desarrolladores a hacer las cosas, y nadie quiere trabajar con una herramienta bloqueada cuyos mecanismos de seguridad obstaculicen la productividad. Una API no tiene valor si los desarrolladores no la consumen, por lo que la facilidad de uso es importante.
Esto significa que los proveedores de API generalmente deberían evitar el tipo de dependencias de sistemas complejos y modelos de gobierno duros que tipificaron las generaciones anteriores de estrategia de TI, pero también necesitan comprender las amenazas actuales y brindar protecciones fuertes que no se interponen en el camino del usuario. Aquí, en base a nuestras observaciones que trabajan con compañías de Fortune 500, hay cuatro precauciones de seguridad que pueden ayudar a los equipos de API a lograr este equilibrio.
API sin autenticación
Las API son las claves de las bases de datos de una organización, por lo que es esencial controlar quién tiene acceso a ellas. Los mecanismos de autenticación y autorización estándar de la industria, como OAuth / OpenID Connect, junto con Transport Layer Security (TLS), son cruciales.
Inyecciones
Las inyecciones se han convertido en uno de los vectores de ataque favoritos de los malos actores. Esta amenaza viene en muchas formas, pero las más típicas son las inyecciones de SQL, RegEx y XML. Las API deben diseñarse teniendo en cuenta estas amenazas y los esfuerzos realizados para evitarlas, y se debe emplear una supervisión activa después de implementar las API para confirmar que no haya vulnerabilidades en el código de producción.
Datos no encriptados
A medida que aumenta la preocupación por la seguridad, el cifrado de datos debe ser una prioridad para las empresas. Idealmente, la información confidencial se cifra desde el punto donde se capturan los datos a través del tránsito, hasta el lugar donde se consumen los datos. Como la capa que pasa datos valiosos entre los sistemas back-end de registro y los sistemas frontend de compromiso, las API juegan un papel importante en este proceso. Para ir más allá del cifrado básico y las protecciones proporcionadas por TLS y los mecanismos de autenticación, los proveedores de API deben emplear herramientas de seguimiento para problemas de depuración, implementar el enmascaramiento de datos para rastreo / registro y aprovechar la tokenización para datos de PCI y PII.
«Reproducción de ataques»
Cuando las API están abiertas al público, se enfrentan al desafío de determinar si las solicitudes entrantes deben ser confiables. ¿Es la solicitud un cliente? ¿O es un atacante?
En algunos casos, incluso si la API detecta y niega con éxito una solicitud que no es de confianza, la API, sin embargo, puede permitir que el usuario potencialmente malintencionado lo intente nuevamente, una y otra vez. Este tipo de supervisión de la seguridad puede permitir que los atacantes intenten reproducir o reproducir una solicitud legítima del usuario hasta que tengan éxito. Las medidas de contador contra estos ataques de fuerza bruta incluyen políticas que limitan la tasa de aceleración de solicitudes, autenticación HMAC, autenticación de dos factores o un token de acceso de corta duración facilitado por OAuth.
Datos en URI
La implementación de claves de API para autenticación y autorización suele ser suficiente. Sin embargo, las claves pueden verse comprometidas si se transmiten como parte del Identificador Uniforme de Recursos (URI). Los datos confidenciales, incluidas las claves API y las contraseñas, pueden ser accesibles para los atacantes cuando los detalles del URI aparecen en los registros del navegador o del sistema. Una práctica recomendada es enviar claves API como un encabezado de autorización de mensaje, ya que al hacerlo evita el registro por elementos de red. Use el método HTTP POST con cargas que contienen información confidencial.
Acelere los negocios sin comprometer la seguridad
Las amenazas potenciales a menudo se pueden evitar al pensar críticamente sobre el diseño de la API y establecer políticas que puedan aplicarse en toda la empresa. A pesar de que un enfoque ágil y basado en la API a menudo implica la descentralización de la administración de TI y brindar a los equipos individuales una mayor autonomía para aprovechar recursos valiosos, la seguridad nunca puede pasar a un segundo plano. Aunque algunos de los problemas en este artículo pueden parecer directos, los hemos encontrado con más frecuencia de lo que podría anticipar. Seguir estas mejores prácticas puede ayudarlo a evitar infracciones y ayudar a su empresa a maximizar el apalancamiento proporcionado por sus API.
