In graduate school, I learned of a system’s safety and progress properties. Safety prevents bad things from happening. Progress ensures that good things happen. Without the balance, a system that does absolutely nothing is likely to be perfectly safe. On this continuum of safety and progress lie the designs of the best systems that you and I use every day.

So let’s think about application programming interfaces (APIs) on this continuum. Not having APIs is the safest choice. But it is the wrong choice. Given that APIs enable new business models, underpin modern digital products and create new business channels, not having APIs hinders the progress of today’s business. APIs that can be broadly adopted are generally a good thing for a business. But then what about safety? What are new attack vectors opening up? The pendulum swings back and forth until the company finds the right balance between the two.

Having been in the API business for over a decade, I saw firsthand how companies wanted to do APIs, yet ended up making them difficult to adopt by hiding API documentation, making signup processes that needed manual approval and implementing other obstacles. The thinking was that if they made using APIs difficult, they would be safer. So, many businesses ended up sacrificing progress on the altar of safety.

Contrast this with a company like Shopify. It offers incredibly complete APIs, usable by anyone who is a developer working with a store. The thinking is that if APIs are easy to adopt, the business will benefit.

But are Shopify APIs less safe? It is difficult to say, but I have not heard of any API vector-based attack on Shopify.

Who Is Adopting GraphQL?

According to a 2020 RapidAPI Developer survey, interest in new API technologies accelerated in 2020, with the number of developers using GraphQL in production doubling from 6% in 2019 to 12% in 2020. Furthermore, the survey found that 71.1% of developers expect to use more APIs in 2021 than 2020, and 21.2% plan to use about the same amount.

Evans Data Corp. announced the results for its Global Developer Population and Demographic Study, suggesting that there are 26.9 million developers worldwide in 2021. SlashData predicts that the global developer population will increase to 45 million by 2030.

So with a 65%+ growth in the number of software developers worldwide in the upcoming decade and the growing interest in GraphQL, millions of developers will potentially use GraphQL for their projects over the next few years. That is awesome. If you build out good GraphQL APIs, they will likely get adopted. Voila, progress!

With GraphQL Comes Challenge and Opportunity

The new, unmistakable shape of APIs is GraphQL. GraphQL makes for a faster, more intuitive API for adoption, because it frees developers to focus on their application logic and abstracts away the backend complexity that slows developers down. Imagine a query that is run against a GraphQL API:

{
  customer(email: "john.doe@example.com") {
    orders {
      total
      delivery {
        expectedDate
      }
    }
  }
}

In one intuitive query, the developer gets all the data to paint whatever web experience she is building. She doesn’t care about the backends; she just gets the data she needs.

Is GraphQL Safe?

Let’s first hear the concerns, which come in three buckets:

  • First, can a developer access something she is not supposed to?
    • With REST, one can slice and dice APIs into API products and restrict access to specific APIs; but in GraphQL, everything connects to everything else. What can be done?
    • GraphQL supports query parameters. So can someone access data they are not supposed to?
    • By introspecting a GraphQL endpoint, a developer now has insights into things she might do with our system. Does it open up new attack vectors?
  • Can the developer, deliberately or inadvertently, ask something that ends up eating up a lot of resources?
    • Can she ask for too much data, such as “Give me all the records in the database if numRecords is the settable parameter”?
    • Can she ask for complex chains that end up using too much processing?
  • Since GraphQL is an abstraction over many systems, how do I manage access to different backends? Even if I solve access to the GraphQL endpoint, I still have to solve for access control to the backends. Am I introducing new problems for managing keys in cloud functions or PaaS layers?

Fundamentally, it all boils down to “REST is fixed, rigid: You ask for X; we give you X” whereas “GraphQL is flexible: You ask for X, Y, Z and you get X, Y, Z.”

None of the concerns in the three buckets above is difficult to solve. However, they must be addressed, and open source and vendor software from companies like Apollo, Hasura and StepZen are doing just that. Some enterprises are taking a position that GraphQL APIs will first be used by their internal apps. Once they are comfortable with the security profile, they will open it up to third-party developers. These businesses are choosing to turn the dial toward safety over progress, toward security over adoption. And that is perfectly OK. But the adoption curve of GraphQL is going to be steep, and I believe that enterprises that remain too cautious for too long are going to suffer the business consequences.

Summary

GraphQL APIs are excellent for frontend developers, providing acceleration for application development and an improved developer experience. However, it poses some new challenges for the security of these APIs. Being a bit cautious early on might not be bad, but keeping the dial turned toward caution will be counterproductive in the long run. So between the safety and progress properties, find the right balance.

At StepZen, we are not only building a GraphQL system that abstracts aways the backends, but are also focusing on the security issues with a goal of continually helping our customers ride the adoption wave while taking care of security concerns.

We are just in the first innings of this journey. Let's get to it!

This article was originally published in The New Stack: The New Stack