3 ms·
I've always thought it's a bit silly have a publicly accessible GraphQL API but then turn off introspection. If the only thing you're relying on to prevent some
by tshaddox 5y ago
I've always thought it's a bit silly have a publicly accessible GraphQL API but then turn off introspection. If the only thing you're relying on to prevent someone from knowing about a certain field is that none of your web client code currently requests that field, you're already in a pretty flimsy predicament. And even then, people could trivially check for common or expected field names, or even brute force a lot of short field names.
If you really intend for your GraphQL API to be used only internally and from your official web client, and you consider any fields not currently requested in your web client to be highly sensitive, you should really turn off public access to the full GraphQL API and use something like GraphQL's persisted queries where your web client requests queries by an opaque unique identifier rather than the fully text of the query.
- slaymaker1907 5y agoSo it's not only security through obscurity, it's very weak obscurity.
- monocasa 5y agoSecurity through the obscurity of a wedding veil. Not only is it translucent, but your audience tends to have a better idea than they can directly see at the moment as to what it's hiding.
- kall 5y agoWell, the gist of the op article is kind of "they can't prevent you from using their internal API", so most services shouldn't try. I think there's still a difference between making people scan your entire frontend code/traffic to find all the edge cases and making them reverse engineer your auth/headers/cookies (hours of work) vs handing them database access after 2 minutes of work. But I appreciate it, and it might be engineers that know this (that preventing access is futile) leaving it on intentionally. I certainly have done that.