GraphQL APIs :Avoiding Security Pitfalls


GraphQL APIs are gaining popularity among API developers with the flexibility it provides to request for the exact data that a user wants and to receive only that. Especially for consumer facing applications backed by APIs, frontend developers love the idea of GraphQL over REST with its ability to fetch the exact  data and to fetch multiple resources in a single request. Along with these dynamic queries and added advantages  it also demands tightened API security. Therefore, it is important to understand the various vulnerabilities associated and align the API security mechanisms in order to get the best out of GraphQL APIs.This article highlights the various security mechanisms that API developers should consider and discuss the possible scenarios where each mechanism is applicable.       

GraphQL, similar to REST, is another way of requesting data through an API. However unlike REST, GraphQL does not under or over fetch data. This provides more flexibility and freedom to the client to receive the exact information that is required. [1] is a quick reference to understand how GraphQL works in comparison to REST. If an organization is strategizing to expose their APIs with GraphQL, it is important to understand that with great power comes great responsibilities. This is to say that while providing the enhanced querying flexibility to the consumers , it is even more important to initiate the right level of security to protect your APIs and data.   

There are 3 main aspects when looking at API security; authentication, authorization and threat protection where the APIs are secured against any potential attacks. 

Authentication layers in GraphQL can be implemented with common patterns such as OAuth. Ranging from the use of JWT tokens which are passed in the authorization header can be checked at the context level of each query. This can be further strengthened with an authorization implementation by delegating any data access logic to the business logic layer and not handling it in the GraphQL implementation.  Use of OAuth scopes would be a good mechanism to handle access control. However, GraphQL developers are usually left on their own to implement the authentication and authorization methods for the APIs.

WSO2 API Manager along with the support to create GraphQL APIs, provides out of the box API security as well. As depicted below, API creators can enable/disable API security ( OAuth) and role based access control by specifying scopes to each GraphQL operation independently.

WSO2 API Manager: GraphQL API Security

With the flexibility of GraphQL, the API consumers have the freedom to come up with various queries which can result in larger  complex queries making the APIs vulnerable. Therefore, it is quite important to have defense mechanisms to protect the APIs. A GraphQL query can take arbitrarily many actions,which means most of your server resources could be consumed. Therefore, simply limiting the number of requests is not a sufficient way of throttling GraphQL APIs. There are three common approaches to this which  are throttling based on server timeouts, maximum query depth and the query complexity. Based on the type of APIs (internal/external) and the use-cases you could use a mix of these as required. 

 For example, throttling based on server timeouts(where a maximum time limit is set for the query execution) is a good approach, if your GraphQL APIs are internal facing where there is good understanding on the various use-cases/usage of the API and such knowledge can be easily communicated to the consumers . If your APIs are consumed by external consumers they might not know how long their queries may take to execute until it is executed at least once hence communicating server timeouts and getting the users to honour it might not work. 

Setting a maximum query depth is also a good approach however, this method alone will not mitigate all the risks. For example a query requesting a large number of nodes in the root level will exhaust the server but will not be blocked in this method. Finally throttling based on query complexity, can be used where you define  complexity(each field/argument will have a complexity figure assigned) for a query and come up with a maximum cost for a given query to throttle from. For example, if a query complexity is 2 and the maximum cost/bucket size is set to 8 a given client can only invoke that query 4 times before they are throttled out.

 In WSO2 API Manager  when creating throttling policies for GraphQL APIs, the user can set query depth limit and query complexity limit as below ,adhering to the above strategies.

WSO2 API Manager: API developers mode to set the field complexity
WSO2 API Manager: Setting max query complexity/depth under throttling policies

Overall it is quite important to understand your API community and the various API security methods that you can/should implement so that you can reap the benefits of GraphQL APIs.


Himasha Guruge

Himasha Guruge

Associate Lead Solutions Engineer at WSO2
Himasha Guruge is a solutions engineer working closely with global enterprises on integration and messaging software projects. She is an Associate Lead Solutions Engineer at WSO2 and has worked on interesting projects in various domains assisting organizations to build API-led integrations. She is an integration evangelist, a speaker, and an author.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture