The Complete GraphQL Security Guide

https://wundergraph.com/blog/the_complete_graphql_security_guide_fixing_the_13_most_common_graphql_vulnerabilities_to_make_your_api_production_ready

by Sytten • 5 years ago

78 16 5 years ago

wundergraph.com

verdverm2• 5 years ago

How does one go from "complete security guide" to "fix these 13 most common vulns to go to prod"?

Leaves me skeptical, especially since they don't talk about good design or dealing with authorization through the resolving process.

jensneuse4• 5 years ago

Author here, the article is already 26 minutes to read, according to some algorithm. I had to cut it somewhere, sorry. Any suggestions are welcome!

verdverm2• 5 years ago

remove the "complete guide" language and use an expanded version as a proper, multipage guide.

I would expect a "complete guide" to take many hours to read

theogravity• 5 years ago

I was hoping that at the end of each section, there would be the actionable items to do / fix, but it seems they're all sort of handled at the end of the article, which was a bit jarring.

jensneuse4• 5 years ago

I get your point. As I'm solving many issues with the same solution, I thought it would work well to split problems and solutions into two separate sections. I can understand where you're coming from though. Thanks for the feedback!

true_religion• 5 years ago

Well since the “solution” is to simply use their SaaS… then they have to wait to the end of the article in order to maintain maximum tension so their marketing pitch will land.

It’s a good article overall though, and I admit I am tempted by their offer… but it’s still a pitch.

SlickStef11• 5 years ago

What's wrong with it being a pitch? The article shows how some problems and then offers a solution to those problems. How would you tell someone about your solution without it being a pitch?

simonw• 5 years ago

It is hard not to interpret the recommendation at the end of this article – which is to wrap your GraphQL API in a locked down JSON-RPC API - as an argument for not using GraphQL at all.

I implemented some of the measures mentioned here - such as execution limits - in my datasette-graphql plugin: https://datasette.io/plugins/datasette-graphql#user-content-...

travisd• 5 years ago

I think the article does a disservice to itself by casually adding in things like "SQL injection" and a few other issues that are really not unique to GraphQL. A more concise article that only touches on the issues that are GraphQL specific would be welcome.

Beyond that, I find the authorization sections unconvincing. As someone who's spent quite a bit of time thinking about authorization in GraphQL APIs, I think that the only viable option for authorization in GraphQL is node level authorization, especially if using the relay convention. You're forced to write every authorization check as a function of the relationship between the user and the subject at hand and it avoids accidentally leaking information (which is also issue with REST APIs that do authorization at the controller level, à la https://news.ycombinator.com/item?id=25728175).

hn_throwaway_99• 5 years ago

OK, this entire article was just completely bizarre IMO:

1. A bunch of the points at the top had to do with writing your own GraphQL parser. I don't disagree this is a complicated task, or that some libraries have implementation bugs, but GraphQL has certainly been around long enough that there are some hugely popular, battle-tested server implementations available. I'm not arguing those implementations are 100% bug-free, but they certainly have tons of eyes on them and are in widespread active development.

2. Many of the bugs have nothing to do with GraphQL. SQL injection or URL path injection are possible everywhere (hint, use a library like slonik that makes it easy to write SQL that looks like string concatenation but actually makes it virtually impossible to have a SQL injection bug).

3. Many of the other bugs are either standard IDOR-type bugs, again possible in any framework, or that arise from a potentially recursive type definition. Yes, if you have different permissions applied at different levels of a recursive hierarchy, you need to be very careful about how those permissions are applied.

4. In contrast to this article, I find GraphQL to be a dream from a security perspective precisely because it is strongly typed. E.g. I define many custom scalar types that I use for inputs that guarantee that by the time I see a value that it is already validated so it can't cause an injection attack. For example, suppose you know all your identifiers are alphanumeric. Just define an AlphaNumericString custom scalar type and you know then that many types of injection attacks would be impossible.

innomatics• 5 years ago

I was surprised there was no mention of whitelisting.

If I know the queries that client apps are going to be running it would be useful to lock the API down to those. It sacrifices flexibility, but if you control apps and server, e.g. a startup then you still get the benefit of flexibility in development. Just need a system of add to the whitelist before deployment.

I have been looking for a way to achieve this with graphene but looks like there isn't a library for that yet. I'm wonder if other platforms offer this?

jjanyan• 5 years ago

I've been wanting this for years and have been tempted to write it myself. I've imagined a way to create your graphql query in a UI then "bookmark" it.

After that you'd grant permissions to use that bookmark via some authentication system. Possibly via a security team or API team to review the implications of the query. Security, performance, etc.

So you get fast and flexible development but you have a minimal surface area when refactoring, auditing security, and monitoring potential performance issues.

One other thing that's useful is for reaching out to the appropriate team to discuss deprecation, security concerns, and new upcoming features. The team that needs to improve the database (in some way) can quickly figure out who to talk to instead of needing to ask multiple teams "hey, we're thinking about X, does that affect you?" The other teams are often busy and it takes time to analyze their code to figure out if it would affect them. It can be a miserable and slow process. With a bookmark, it's obvious and straightforward.

If anyone is familiar with something along these lines I'd love to hear about it.

jensneuse4• 5 years ago

The proposed solution does exactly what you describe in the first part. By turning GraphQL Operations into an RPC endpoint, we've essentially whitelisted the Operation. We've not only whitelisted the Operation but added a whole lot more but obviously I don't want to repeat the article. If you're interested discussing this further, find my contact information at the end of the blogpost.

frob• 5 years ago

If we search the same source for the birth of GraphQL, we can see, it's Sep 2014, around 7 years old.

GraphQL is a little older than that. It was initially developed at Facebook in 2012. It says as much on the graphQL website right on the main page: https://graphql.org

fulafel• 5 years ago

What is meant by operation validation here? (I'm not familiar with graphql)

edit: according to most explanations it's about catching accesses to nonexistent fields, cycles, and other things you'd like a nice error message from - would be interesting to hear some security relevant cases.

The Complete GraphQL Security Guide

Related Stories