The importance of API security is constantly exemplified. Last week, Rapid7 discovered a leak in GitLab’s GraphQL API. The security researchers managed to retrieve personal data without authorization. Although the leak has since been plugged, the incident points to a larger problem.
GraphQL is a query programming language for APIs. Its syntax and model are popular among organizations like Facebook and GitLab. Unlike REST APIs, GraphQL works with a single endpoint per application. Upon connection, all exposed application data becomes available.
Some organizations configure GraphQL to only respond to queries from authorized clients. Other organizations work with multiple privilege levels, gating data access based on privilege level.
The latter is error-prone. Rapid7sSecurity researchers accessed GitLab’s GraphQL API to retrieve (user) names, email addresses and photos. The research team had no authorization. Names and mail addresses are plenty of ammunition for social engineering and espionage.
The problem with WAFs and API Gateways
GitLab’s GraphQL API has since been patched, but the incident points to a larger problem. Sloppy API configuration and development creates serious risks.
Although Web Application Firewalls (WAF) and API Gateways can block suspicious traffic, that’s insufficient for GraphQL APIs. GraphQL allows applications to be split into parts (objects) and exposed depending on privilege levels. WAF and API Gateways have no idea of an object’s contents and whether it should be exposed or not.
The problem calls for a modern solution. Some developers, including Noname Security, go well beyond WAFs and API Gateways. Noname Security’s platform is both capable of intercepting suspicious traffic and analyzing the configuration of APIs. In the case of GraphQL, the platform assesses whether object access is verified. GitLab’s leak could’ve been avoided.