As Roy Derks said, “GraphQL will do to REST what JSON did to XML.” Numerically, Roy is correct. GraphQL is a query language was announced by FaceBook in late 2015 and has grown significantly in popularity.
A Quick Review: REST APIs and GraphQL
When your React, Angular, or Ember website calls for information from a server, there has to be a protocol and method for identifying yourself, as well as identifying what information you are looking to receive.
REST is the current industry standard for API calls to a server because of its simplicity, discoverable endpoints, and magnitude of libraries for support. REST security is typically simple and easy to implement. You have a limited set of reports, and usually, by managing which endpoints a user has access to, you can limit their data access.
REST has its limitations, including a disregard for the size and speed of the network traffic. Since the endpoints are quite discreet, the entirety of the data fits within those designated views with little variance. This leads to a slow client/server interaction.
Let’s say, for example, that you need to transmit an online video. Does it make sense for you to send all of the video comments along with the video data? Wouldn’t that be overkill? If you choose to separate the comments on the video into a separate resource (as you should in REST), your application must make TWO SUBSEQUENT CALLS over the network. This does not include transforming, parsing and architecting your second API call.
You might wonder, “Couldn’t I pass a parameter to the REST API call, letting it know what items I want, and what Items I don’t?” Now you’re thinking in GraphQL. GraphQL allows you to do that, and more. It’s a single endpoint that returns flexible data structures. However, while enabling the requestor to grab the information they want is powerful, it’s also dangerous.
Security Risk #1: Discoverable Attack Points
One of the amazing aspects of GraphQL for developers is how easy it is to discover resources and query them. Not only you can guess resources, but you can also use Introspection to identify the keys and abilities you have on that resource. Though this is excellent for development and staging, you might be able to identify how such a thing is dangerous in production. Surely, you hope that all your resources are secure, but people make mistakes. So why allow malicious users the ease of discovering, guessing, and accessing data they were never meant to have.
Be sure to disable introspection in production. Though this isn’t officially supported yet, there is a Node module to do so. This will help protect you from prying eyes, and even information gathering scripts that are engineered to identify all resources possible.
Security Risk #2: Parameter Smuggling
Allowing the client to identify what they need requires server protection. Even if you’re writing the client application, and you’re only asking for the resources a client might need, a malicious user could add their own additional keys to your request. Client-only security notoriously keeps out the honest.
You might think that guessing those missing parameters would be difficult, but keep in mind a completely legitimate application could be used to fish out parameters, and then an anonymized malicious account could attempt to access administrative keys on other accounts. For more examples on parameter smuggling, see this article where the account license key was accessible from an unprivileged account.
Security Risk #3: SQLi
Many of you are familiar with SQL injections. As a quick analogy, if you asked for my name, and I said “<My Name here> who happens to be the best person I know!” Now every time you introduce me, I get a bit of elevated social status! All joking aside, that’s exactly the problem of SQL injection. Parameters given by the client go unquestioned and unfiltered, resulting in modifications and access elevation for the client.
REST doesn’t really allow the client to ask for much in specifying data, and so this classic problem has only re-emerged with the growth of GraphQL. GraphQL doesn’t itself prevent any kind of attack, so the implementation of GraphQL must be checked. You can incorporate this measure into your secure coding policy, especially as part of a SecOps or DevSecOps approach.
Fortunately, the fixes are the same as they’ve always been, and you can refer to OWASP for security tips. Use parameterized queries and sanitize all input. Advanced attackers are very skilled at finding SQL injection mount points and now that they have a new field to do so, those ignorant to the dangers will find themselves severely outgunned. Don’t trust any query input, not even scalars! Sanitize input, write prepared and stored procedures, and finally, limit the surface area an attacker can hit by limiting production introspection in Danger 1!
Conclusion
GraphQL isn’t trying to hide its identity. It’s not even trying to hide what resources are possible. It’s clear and discoverable, which means it’s an easy mark for devs and snooping. Lock your system down, and be sure to check for issues. It’s important, especially after any tech switch, that you monitor and report on all aspects.
GraphQL clients like Apollo, haven’t had any major CVE threats, but having a good threat reporter is essential in these situations. It helps you identify strange usage, and in the case of a breach, you can identify what was affected for repair. New tech must be monitored! GraphQL will continue to be more and more popular, so familiarize yourself with the three above threats so you can quickly address any security risks.
Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Imperva, Samsung NEXT, NetApp and Ixia, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership. Today he heads Agile SEO, the leading marketing agency in the technology industry.