API-10 Unsafe consumption of APIs

Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer

Get a Demo

Katie Paxton-Fear

And at long last we get to number 10, unsafe consumption of APIs, and this particular flaw has been on everyone’s mind recently, though you might recognise it as “prompt injection” a type of issue you can find in LLM applications. This flaw is simply trusting that a third party, downstream API your application uses has a safe output that you can process. We see this a lot in applications that trust output from LLMs like ChatGPT or GPT-4, imagine an application that automatically runs code provided by a ChatGPT API response, a user could adjust the prompt so the API returns unsafe code, which is then processed.

Why is this an API specific security issue? Well APIs will often integrate with each other, whether that’s a social media application that enables websites to embed posts or an integration in an enterprise application. As these are APIs with standard outputs we tend to trust them, however we can’t always ensure these are safe especially when used far downstream. The impact of these could range from full compromises to an issue like cross-site scripting.

Suzy’s Social has quickly become a top social network, with her team adding dozens of additional features. A very popular addition is integrations with marketing tools, tracking the performance of posts and adverts, scheduling posts across many platforms and analytics that track account growth. With all of these new features they’ve invested heavily in identifying and investing in third party applications. Initially these would be setup by asking for account permissions and posting as if they were a user, but moving them to be in-house has enabled Suzy’s team to have a better oversight of the security of these applications. Adam, the attacker, does look at these once or twice but for the most part he has lost interest in Suzy’s Social.

Viv, our victim, has become a top creator on the website and she has invested into a lot of third party tools to track how well her work is doing. Adam realises that Viv is using these tools and decides to try a credential stuffing attack to see if he can gain access. Unfortunately these marketing tools have not invested as heavily into security so he easily defeats the password and logs in to her account. While investigating he realises that the marketing website uses a different API to the API that Suzy’s Social uses. He tries a few different attacks and realises that this third-party API doesn’t have the same filtering as the main API. He crafts a cross-site scripting attack that targets the change password API endpoint, easily using a <script></script>. Anyone who reads Viv’s post will have their password changed, and unfortunately as a top creator on the website that is a lot of viewers.

The resolution for this issue is fairly simple in theory but difficult to implement in practice. API responses should be treated like user input, with the same filtering, protections and considerations as any other form of user input. This can be challenging in an API environment as integrations rely on trusting that input. Mitigations developed for other software supply chain issues can help build that trust, such as a software bill of materials, however this is not guaranteed to prevent these attacks. Any filtering or protection on user input should also be applied to API responses, particularly WAF-based solutions.