Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.
> the idea of exposing queries from the client directly to the DB is totally bananas
I don’t necessarily disagree but going to play devil’s advocate here on this common foundational viewpoint. Why is this bad? In fact, why not expose the DB directly to the client?
“Additional layers” and “don’t explain DB structure” is security through obscurity. If a DB manages access control directly (field-level or partition-level granularity), any permissible query should run. To prevent pathological queries, add role-based resource quotas and back-off policies.
What about zero day vulns? Well these are going to be a problem regardless of the presence of various infra layers on top of the DB; you’ll have to monitor for data exfiltration to detect these types of attacks in either case.
There’s not a database I’m aware of that handles all of the above considerations, but oftentimes security issues exist in the overlooked gaps that arise between the complex interplay of many dependent systems. If you move the responsibility for security to the DB itself (other than authentication), you’ve removed a lot of the “confusion” that can be exploited, and overall security then depends on just a few factors: 1) correct assignment of DB access permissions, 2) valid external authentication, 3) quality of data exfiltration monitoring.
You might say you’re one simple DB misconfiguration away from disaster, but again, this is already a problem. The benefit of this alternative approach is that you have now shifted the bulk of the security work to one place: very careful rollouts of changes to DB access permissions. You would conduct static analysis to determine the “diff” of how data access has changed and perform sandbox tests. In exchange for this additional work, you can quit worrying about the security of anything downstream of the DB, assuming authentication is set up correctly.
I'm not saying security by obscurity is true security. It's one thin layer, though.
>> If you move the responsibility for security to the DB itself (other than authentication)
And what about all the possible access levels within your auth? Should every DB view have to check a user table to authenticate that the viewer has the priority level to select on it? If it doesn't, all I need to know is the name of a view I'm not supposed to see. What happens if you add a new security level... you change every single view definition? What if your auth + user levels are in a completely different DB in another time zone? Why put that burden on the DB if you get flooded with bad queries from hundreds of clients? That's why I say it's crazy, instead of writing an API endpoint that runs auth first and knows which views or tables are accessible from there and to which users, all in one place. Yes you have slightly more work conforming the client data definitions to whatever is returned from the API, but that seems like a very small price to pay to put all your security and filtering/validation in an easy-to-read middle layer. Of course you should use views and DB perms, but those are not sufficient if someone steals a login or session unless there's a middle layer checking their IP and hash and potential double-taps and lots of other markers that it might be a rogue query before it goes to the database.
Not a fan of GraphQL (the problems mentioned in the post are very real), but GraphQL specification does not say anything about the DB design / queries. It is still an API layer and you are free to model it in any way you want.
Indeed, from one of the authors of graphQL on this very forum:
"That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1]
"GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2]
Graph models need not be your tables . They should reflect your data models, the same kind of models that would have been exposed in a traditional RESTful API?
Similar concepts of allowing queries and response formats was there in other standards and not new ?
OData is fairly popular in REST world , even older , SOAP XMl had supported with custom query language one robust one I remember T-SQL used in Taleo the old Oracle hiring software
There are many examples of clients doing joins and queries in other standards , it is hardly unique to GraphQL
thats not a graphql thing. my startup uses graphql and it does not map anywhere near closer to 1:1 with our database. what you're talking about is the litany of RAD api backend apps that take your db and expose a graphql endpoint.
