The Complete GraphQL Security Guide
wundergraph.com
wundergraph.com
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.
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).
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-...
It’s a good article overall though, and I admit I am tempted by their offer… but it’s still a pitch.
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?
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.
Leaves me skeptical, especially since they don't talk about good design or dealing with authorization through the resolving process.
I would expect a "complete guide" to take many hours to read
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
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.