What We Learned from These 3 API Security Breaches

They say, “Experience is the best teacher.” Well, they never said it had to be your experience. If we look closely, there are lessons to be learned from these five fateful API attacks that can help any organisation secure its APIs better.


Here they are.


Zendesk 2017

The scenario: The helpdesk ticketing platform Zendesk was exposed to attackers thanks to a SQL injection vulnerability in a GraphQL endpoint. A second flaw would allow attackers to, “steal data from any table in the target Zendesk account’s RDS, no SQLi required.” Security platform Varonis reported the bugs to Zendesk, and the company was able to repair the damage within a week. No sensitive data was exposed, but had the vulnerability been discovered and exploited by malicious actors, customer comments, conversations, email addresses and tickets could have been compromised.


The solution: GraphQL is susceptible to injection attacks for a number of reasons. It introduces new processing steps – the parser, the gateway and the sub-graph resolvers – which can each be exploited as an attack vector. It also turns multiple API calls into a single call, so more SQL injection damage can be done with a single stroke. Protections against this are basic; sanitize your database inputs, use stored arguments or prepared statements which cannot be interpreted as code and apply the principle of least privilege to all database clients.


Dropbox 2022

The scenario: This notable API attack started out as a phishing scam. In October of 2022, Dropbox was hit by a malicious actor who illicitly gained access to their GitHub source code repositories and accessed “a few thousand names and email addresses belong ..

Support the originator by clicking the read the rest link below.