GraphQL API authorization vulnerability found in large B2B financial technology platform

Cybersecurity firm Salt Labs discovered a GraphQL API authorization vulnerability in a large B2B financial technology platform. It would give attackers the ability to submit unauthorized transactions against customer accounts and harvest sensitive data, all by manipulating API calls to steal sensitive data and initiate unauthorized transactions.

Salt Labs would not say which company was affected as a way to protect users, but it explained that the vulnerabilities have been fixed since they were discovered. The platform offers financial services in the form of API-based mobile applications and SaaS to small- and medium-sized businesses and commercial brands, according to Salt Labs. 

Michael Isbitski, technical evangelist at Salt Security, told ZDNet that GraphQL API adoption is slower than REST but growing rapidly because of the potential benefits to front-end design and performance. 

A recent survey from Postman found that while most companies use REST, GraphQL and others like webhooks, WebSockets, GraphQL, and SOAP are gaining traction. 

“Authorization flaws in APIs are very common, hence why they land on the OWASP API Security Top 10 list,” Isbitski explained. “This type of authorization flaw is also more likely to occur with GraphQL APIs as opposed to REST APIs just because of the nature of how GraphQL can be used to combine API calls and mutate queries.”

Salt Labs identified this vulnerability in the company’s SaaS platform and mobile applications it interfaces, resulting from the failure to implement authorization checks correctly. Researchers found that some API calls were able to access an API endpoint that required no authentication, further enabling attackers to enter any transaction identifier and pull back data records of previous financial transactions. 

The company said GraphQL APIs are “inherently difficult to secure” due to their unique flexibility and structure.

Salt Security CEO Roey Eliyahu said GraphQL provides some advantages in query options compared to REST APIs, but this flexibility comes with risk. A single API call can include multiple separate queries. 

“A prevalent vulnerability related to GraphQL is that developers must implement authorization on every layer of a multi-layer GraphQL query to prevent attacks. This side effect increases the burden on development and operations teams, and it can extend delivery timelines for applications with many API endpoints,” the researchers wrote in a report about the issue. 

“It also can create a situation that is more vulnerable to human error. Some endpoints may be forgotten or not properly dealt with, causing its own set of issues down the road.”

The researchers explained that the authentication and authorization in mobile app designs are often broken or absent because developers focus on usability. Cyber criminals often know that codebases are managed by different teams and search for vulnerabilities in both front-end clients and back-end services. 

SSL or TLS typically encrypt web API communications, giving enterprises the sense that they are protected when, in many cases, they may not be. 

“The prevailing assumption in the industry around GraphQL is that these APIs are uncommon, obscure targets of attack and therefore safer,” Isbitski said. “This assumption is wrong. Security through obscurity has always been a poor strategy, and the complexity of GraphQL APIs makes securing them more challenging.”

Netenrich threat hunter John Bambenek told ZDNet that when mobile app developers make applications and API services, they wrongly believe an attacker could not misuse this information, since the phone itself doesn’t provide visibility.

“It is tempting to believe that mobile apps create an obscurity layer that is hard for attackers to crack, but decades of experience show that security through obscurity just doesn’t get the job done,” Bambenek said. 

“Organizations need to make sure every transaction requires authorization and every step of a transaction is checked to make sure the permissions are appropriate for what is being attempted.”