The main story this week comes from HackerNews and describes how attackers are able to exploit improperly secured Google Cloud Platform (GCP) tenants. The impact on affected users included compromising their cloud resources, like uploading cryptocurrency mining software, and ransomware and phishing attacks.

Of greatest concern is that the accounts could be compromised due to lack of basic hygiene on the cloud tenants. The most common issue as well as exploit — affecting 48% of the instances — was weak or no password on user accounts and API connections that allowed attacker easy access to the cloud instances. Other exploits included installing third-party software in the cloud instances and leaking credentials through GitHub repositories.

The key takeaway here is that whilst cloud platforms are a great business enabler, their complexity frequently leads to misconfiguration which results in potentially vulnerable deployments. Additionally, many skilled attackers will know what the common misconfigurations are and home in on them, allowing them to easily exploit them in the attacks on systems.

An interesting article this week by Tj Blogumas describes a novel approach to using GraphQL as an API gateway.

Blogumas describes a typical design problem encountered in the adoption of a microservices architecture: how to present a single fronted to consumers without exposing the complexity of the backing microservices mesh. Traditionally, this has been the domain of the API gateways, but Blogumas demonstrates how a GraphQL frontend can achieve the same effect.

Of interest here is how you can implement security controls at the GraphQL gateway level rather than in the backing microservice APIs. The key advantage to this approach is that key security controls are centralized in one place — implemented only once at the gateway level, rather than at in individual APIs. This reduces the burden on development teams and reduces the likelihood that such controls get accidentally omitted.

Blogumas provides several examples of the type of security controls that can be implemented, such as:

• Depth limiting: Reduce the depth of allowed queries to reduce the impact of Denial of Service (DoS) based attacks.
• Rate limiting: Reduce the rate at which requests can be made to specific API endpoints to mitigate the effect of DoS or brute force attacks.
• Query cost limitations: Reduce excessively complex queries to mitigate DoS attacks.

An interesting take on API architecture that we will surely hear more about.

We have featured some excellent API security guides in this newsletter (such as the one last week by Inon Shkedy), and this week it is the turn of the “Awesome API security” guide by André Rainho.

This vastly comprehensive guide covers, for example, the following topics:

• Tools
• Mind mapping
• Checklists and cheatsheets
• Training, walkthroughs, and laboratories
• Enumeration and scanning
• Fuzzing and API keys
• Firewalls
• Presentations, videos, playlists, and podcasts
• Design and architecture
• Specifications

This is bound to prove an invaluable resource for anyone working in or around API security — thanks to André for this great resource!

Finally for this week, we have news of upcoming API security training courses by the AppSecEngineer team, featured in their review of API security in 2021.

The course includes a deep dive into both offensive and defensive techniques for API developers. On offense, it covers typical vulnerabilities specific to REST APIs and how malicious actors can exploit them. On defense, it focuses on defensive techniques in a hands-on laboratory environment that follows the OWASP API Security Top 10 as a content outline.

It’s always good to see new API security training and — based on previous AppSecEngineer courses — this should prove to be a great success.