MY TAKE: GraphQL APIs rev up innovation – but also introduce a potential security nightmare

The software developers who are creating the coolest new mobile apps have a secret weapon. It’s called GraphQL.

Related: How APIs expand the attack surface

GraphQL is a leading-edge approach to deploying APIs, the software conduits that mesh together all of the digital services we use every day and have come to take for granted.

Like every other Internet breakthrough, GraphQL comes with a security tradeoff. A big one. API deployments — and API security vulnerabilities — have been exploding exponentially for the past decade. It should come as no surprise that businesses have glommed onto the data sharing and monetizing benefits of APIs while overlooking the security ramifications of APIs left unprotected.

Now along comes GraphQL, touted as a pathway to new horizons of business agility and user experiences, but also introducing a vast new tier of security exposures – all at the API level. Going forward, what we do about API security, generally – and these new GraphQL data exposures, in particular — will determine the level of privacy and security – or insecurity – we’ll all have to live with.

Quixotically, GraphQL comes to us courtesy of Facebook. In 2015, the social media giant released GraphQL as an open source project. “GraphQL was our opportunity to rethink mobile app data-fetching from the perspective of product designers and developers,” wrote Facebook’s Lee Byron in a blog post. “It moved the focus of development to the client apps, where designers and developers spend their time and attention.”

We’re still early in the adoption curve for GraphQL, but adoption appears to be on a steep trajectory. At the data layer, GraphQL had the top awareness level rating – 98 percent — as well as the top satisfaction rating – 94 percent — among 23,765 people in 137 countries who were polled as part of the 2020 State of JavaScript report. This reflects how prominent, app-dependent companies are using it in live operations and singing its praises. This includes the likes of Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, The New York Times, Shopify, Twitter, Pinterest and Yelp to name a few.

I’ve had a few thought-provoking discussions about this with Doug Dooley, chief operating officer at Data Theorem, a Palo Alto, Calif.-based software security vendor specializing in API data protection. Here are a few key takeaways:

How we got here

Companies have spent hundreds of billions of dollars over the past 20 years taking a “layered defense” approach to defending their on-premises endpoints and data centers. Then along came digital transformation – and the irresistible pressure for companies to digitize or die.

We’re deep into our transition onto the public cloud and rich mobile user experiences. Leveraging processing power and data storage supplied by the likes of Amazon Web Services and Microsoft Azure has become de rigueur, and software-as-a-service offerings, like Office 365 and Zoom, have become our baseline work tools. Meanwhile, smartphones and mobile apps have become our go-to user interfaces.

APIs are the glue that makes all of this digital agility possible. API deployments have scaled so broadly and so fast that many companies don’t know how many APIs they have nor which types they’re using. Meanwhile, ignorance about the scale and scope of API vulnerabilities runs rampant.

Dooley observes: “What’s happened is the advent of the cloud has destroyed the Enterprise perimeter. Sensitive data that used to live in a data center now lives on the Internet, in cloud data centers, so data gets spread all over the world, all of the time.

“It’s not that the perimeter has gone away. The perimeter now lives in these things called APIs, that is the network transport we have today. Therefore, APIs really should always be encrypted and should always have authentication, authorization and audit trails.”

Ideally, businesses would fully understand the cyber risks posed by APIs and thoughtfully account for them. But things are far from ideal. Digital transformation has taken on a life of its own, creating an environment where competitive agility trumps everything. Developers are encouraged to innovate on the fly and can spin up new APIs in a matter of minutes, so the number of APIs keeps rising exponentially. And today a large proportion of APIs – on the order of hundreds of millions of them – lack even rudimentary security controls.

Facebook’s choke point

Into this milieu, engineers at Facebook contributed GraphQL, a new data query language for APIs and a cyber risk wild card. This happened in 2012, when the social media giant encountered a choke point. Facebook’s latest, greatest mobile apps no longer flowed seamlessly to both Apple iOS and Android smartphones. Facebook determined that this was because REST APIs were not up to the task.

Some context: REST, which stands for “representational state transfer,” is a data query language. Internet commerce as we know it today is built on REST APIs, which have proven to be very reliable and scalable. However, REST APIs are also rigid. Facebook discovered that REST APIs are not well-suited to handling the highly complex data exchanges it takes to deliver leading-edge mobile apps. For example, REST APIs are not very good at delivering one version of a new Facebook app to an iPhone and yet another version to an Android device.

“At the time, our iOS and Android apps were thin wrappers around views of our mobile website,” says Facebook’s Byron. “While this brought us close to a platonic ideal of the ‘write once, run anywhere’ mobile application, in practice it pushed our mobile-webview apps beyond their limits. As Facebook’s mobile apps became more complex, they suffered poor performance and frequently crashed.”

So, Facebook’s developers concocted a new and improved data query language for APIs – GraphQL. They modeled it after SQL, the tried-and-true data query language that enables websites to tap into their underlying databases.

“GraphQL enabled developers to showcase and organize data in their apps in an efficient and effective way,” Dooley says. “GraphQL works very much like a SQL database call. For a developer, it’s awesome for data retrieval, data performance and data flexibility.”

GraphQL eliminated the choke point frustrating Facebook’s developers – and it quickly gained traction with companies in the vanguard of digital transformation. Airbnb, for instance, made a massive investment in GraphQL, putting it at the center of its API strategy across both its product and internal tools, reported Adam Neary, an Airbnb tech lead, as part of GraphQL’s official Linux rollout.

Too much discretion

GraphQL’s core benefit is that it introduces a form of universal data access at the API layer. At the same time, this is also its core security flaw.

Nimble data access is all fine and well, as long as identities get verified, sensitive data gets properly segmented and privileged access gets wisely implemented. These fundamental cyber hygiene practices are still sorely lacking in the business landscape overall, especially at the API layer.  And here comes GraphQL empowering app developers to make many more data queries and creating many more access points that need to be accounted for.

“This can be very dangerous because if you can get a hold of a GraphQL API that’s unprotected, you’ll probably have access to every data record available on the back end,” Dooley says.

Researchers have begun delineating GraphQL’s most glaring security soft spots, of which there are many. For instance, GraphQL’s authorization logic is designed mainly to support data validation. Individual developers must take the initiative to come up with authentication and authorization routines for any new API they put into motion.

GraphQL’s open architecture is rife with these types of very broadly defined components that leave much up to the discretion of individual developers. It’s easy to see that many, if not most, developers aren’t going to want to detract from agility to account for security, particularly if there’s no compliance edict compelling them to do so. Threat actors know this and there should be no doubt that they are moving to take full advantage.

We’ve already reached the stage where malicious hackers are fully focused on exploiting flaws in REST APIs. The elite hacking groups frequently pivot to API manipulations at key junctures of multi-staged hacks. The encouraging news is that cybersecurity vendors, Data Theorem among them, are designing and delivering tools that can put organizations in a good position to protect their APIs from being used against them.

Balancing agility and security

During one recent Internet-wide scan, for instance, Data Theorem researchers found a website selling high-end art and using GraphQL APIs to promote its services and conduct transactions with its partners and customers. GraphQL gave the art website the ability to leverage data from an array of data sources and thereby deliver cool customer experiences.

Yet the developer who wrote the app failed to implement even very basic security protections, measures that wouldn’t have unduly detracted from the user experience, but would have at least slowed down a threat actor who happened to be probing for a way in through a GraphQL soft spot, which is exactly what Data Theorem’s Analyzer Engine quickly found.

“We were able to literally start walking through their entire database, which showed their customers, their product inventory, their prices, and credit card fields that I’m pretty sure they would not want exposed on the public Internet,” Dooley told me. “Because of the way they implemented GraphQL, it was relatively easy for us to ‘hack’ their APIs and get access to all of that data.”

It has only been in the past couple of years that a small segment of organizations have begun to treat API exposures as a clear and present cyber risk, one that warrants proactive mitigation. Dooley makes a strong argument that APIs represent the new Enterprise perimeter that matters. I’m encouraged that API security risks have now surfaced as a major topic in the cybersecurity community. A clean break from the legacy approach to defending business networks is long overdue. There’s a long way to go, but things are moving in a positive direction. I’ll keep watch and keep reporting.

Pulitzer Prize-winning business journalist Byron V. Acohido is dedicated to fostering public awareness about how to make the Internet as private and secure as it ought to be.

---

(LW provides consulting services to the vendors we cover.

 

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at: https://www.lastwatchdog.com/my-take-graphql-apis-rev-up-innovation-but-also-introduce-a-potential-security-nightmare/