Application programming interfaces (APIs) are essential to the functioning of the cloud. APIs are what allow access to and management of cloud services. They also are frequently used to connect microservices, such as containers, within the cloud. In the last decade, application development has moved away from the creation of one monolithic application in favor of microservices for various application functionalities. This provides the benefit of agility in updating specific features and scaling as needed, without the risk of breaking the entire application.
The increased use of microservices APIs, in combination with rapid digitalization during the COVID-19 pandemic, has helped fuel the extensive growth of API usage over the last few years. Despite their ubiquity in modern application development, however, APIs remain one of the weakest links in application security if incorrectly configured.
APIs are a frequent target for attackers because they can provide direct access to valuable data and a way into the backend of your company’s systems. APIs are also difficult to secure due to authorization and authentication challenges and insufficient secret protections. Cloud APIs are subject to these same issues, in addition to other risks stemming from the unique cloud environment.
Unsecure API Keys Can Lead to Leaked Cloud Meta Data
Cloud service providers offer a Cloud Instance Metadata API, which is allowed to access data about a running virtual instance. This is used to make it easier to manage applications but can also be a security risk, as the information the API provides includes sensitive data like credentials. If an attacker already has a presence in the instance, they likely have access to this API. They also can use server-side request forgery (SSRF) to gain access. One way to prevent this is using a web application firewall (WAF) to block SSRF attacks. Another mitigation method is being mindful of the metadata services available, disabling unnecessary ones, and restricting insecure versions.
Identity Confirmation at Many Access Points
Where once there were few points of exposure for an application, now there are numerous, as each microservice and the APIs connecting them are publicly exposed. In order to enforce a zero-trust policy, the principle of least privilege must be applied to each microservice, and authentication and authorization take place at each API. Not all users should have access to all APIs in order to reduce the likelihood of an attacker gaining access through one API and compromising the entire application and all of its data. This restriction of permission can be done through an access control framework such as OAuth2, which offers token-based access and authorization. This, in combination with an API gateway, can help enforce least privilege.
In addition to verifying the identity of the entity making the API request, API security requires transport-level security (TLS) encryption between client and application. It is important to enforce encryption between microservices to avoid attacks designed to intercept sensitive information internally.
Understanding Shared Responsibility
An organization that is using a public cloud has a shared responsibility for security with the cloud service provider. How much of that responsibility is taken by the CSP and how much is left to the user of the service depends on the service model (IaaS, PaaS, SaaS), but there is always some degree of shared responsibility. CSPs provide their clients with APIs to enable the functionality of these services. Those APIs can be proprietary, only working within their environment, but increasingly, there is a push for cross-platform APIs to support the growing use of hybrid and multi-cloud environments. Users of these cloud APIs may not know what they’re responsible for when it comes to API security and security of the APIs’ keys. CSP customers will need to be aware of when CSPs make updates to APIs, as it may change the configurations required on their end.
APIs Not Always Built with Security in Mind
The cloud has facilitated a move towards a CI/CD pipeline with a rapid development and release cycle. This may be good for business agility, but it can pose a security risk if security is not incorporated early in the development process. While many organizations are adopting this type of “shift left” approach, this is not always applied to APIs. APIs tend to be built with functionality in mind, as opposed to a security-first mindset. It is an API’s job to share data, so restricting access to that data is not always top of mind, but authentication and authorization are critically important in API security.
Progress is being made, however, to bring API security to the forefront and integrated into regular vulnerability testing. In 2019 OWASP released a specific top ten list for API vulnerabilities which identifies common issues, such as broken user authentication, broken authorization, and excessive data exposure, that are frequently encountered. This list can be used in conjunction with the OWASP vulnerability list for applications to ensure better all-around application security.
Interested in evaluating your API security? Check out this RFI on Member Exchange on API security assessments. RH-ISAC members have access to resources like this, as well as a discussion forum to seek advice from fellow members. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
