GraphQL is great for public data and endpoints. Or endpoints that are completely system to system, single-tenant, “we can give the user all the data we hold” integrations. That is, internal integrations where authorization is handled elsewhere.
Exposing a GraphQL endpoint has the same issues as exposing a DB. You need to define granularity of access to each individual table, column and row for each user.
I’ve yet to find a GraphQL interface that doesn’t expose too much information or fail to follow the principle of least privilege. Even IKEA, who I think has possibly the best GraphQL corporate-built implementation I’ve ever seen, exposes a little too much.
Think about your IAM environment and all the exceptions you need to grant users. The same thing exists for data and eventually the ease of use we trade for developers to rapidly prototype results a data breach. Why? Because someone enabled introspection to debug a production issue, or forgot to tick a box or define a parameter when deploying a data model change. Boring old RPC and REST typically doesn’t carry this level of risk, or has tooling to prevent it.
As someone who chases bug bounties, please keep building out GraphQL. My mortgage appreciates it.
But as someone whose day job is more on the blue-team side - no, you won’t get my sign-off. This is not acceptable risk.
How does REST solve this any better? As soon as you have certain entities or fields which are visible only to certain subsets of users, surely the problem complexity is essentially the same.
In theory REST doesn’t, in practice it does. The reason why is because most RESTful interfaces are built and deployed separately. You don’t throw an interface on top of a data model and presto, you’ve accidentally exposed your customer data to the internet.
The other aspect is with REST the interface is strictly defined. There’s no unknown data being disclosed, you’ve defined the resource and understand the authorization required by building it in the first place. Yes, mistakes are made by engineers who don’t understand what PII is or don’t care what the access control for the endpoint looks like, but at least you can spend time actually scoping it and defining what that looks like.
How do you threat model a constantly changing database? You could throw flags on fields and have that tie in with your GQL orchestration lib/tooling, but that’s something that very, very few organisations can get right.
Not even 1%, I’d say maybe less than 100 in the world.
Exposing a GraphQL endpoint has the same issues as exposing a DB. You need to define granularity of access to each individual table, column and row for each user.
I’ve yet to find a GraphQL interface that doesn’t expose too much information or fail to follow the principle of least privilege. Even IKEA, who I think has possibly the best GraphQL corporate-built implementation I’ve ever seen, exposes a little too much.
Think about your IAM environment and all the exceptions you need to grant users. The same thing exists for data and eventually the ease of use we trade for developers to rapidly prototype results a data breach. Why? Because someone enabled introspection to debug a production issue, or forgot to tick a box or define a parameter when deploying a data model change. Boring old RPC and REST typically doesn’t carry this level of risk, or has tooling to prevent it.
As someone who chases bug bounties, please keep building out GraphQL. My mortgage appreciates it.
But as someone whose day job is more on the blue-team side - no, you won’t get my sign-off. This is not acceptable risk.