Hacker News Reader

Comment by kall | Hacker News Reader

When they have a GraphQL API with introspection enabled, it feels like discovering a pot of gold.

This happens more often than you would expect, even without any auth sometimes. At that point you're basically developing with the same DX as internal developers.

My theory is people just turn off the GraphiQL endpoint on their GraphQL server and think they have hidden the schema, not realizing any external tool can do the introspection. Either that or it's developers slipping a little something under the radar for other developers (same thing with source maps).

Another tip: If the service in question has a mobile app, sniffing the traffic on that with a MITM proxy can yield more interesting results than a web app.

View on HN

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.

So it's not only security through obscurity, it's very weak obscurity.

Security 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.

Well, 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.

You may not even need introspection--

https://github.com/nikitastupin/clairvoyance https://github.com/swisskyrepo/GraphQLmap

Some GraphQL APIs do this on purpose if the API is meant to be completely public and if they want to allow self discovery and documentation of things through introspection. Allows anyone to point their own instance of GraphiQL or GraphQL playground and the endpoint and find things out. We even include comments in the schema to help with this as another form of documentation.

I saw a website that exposed the results of a very expensive paid Linkedin API + the enrichment they did to those results in their GraphQL endpoint. Seemed like an expensive oversite

Which site was that??

Just be ready for mitm proxying on some mobile apps to be a bust if they use certificate pinning. I’m not aware of anything that can get you past that besides patching the app itself.

There's plenty of Frida scripts that can disable app certificate pinning

To be fair I’m sure that uses patching but I didn’t know about that tool and how easy it is to use. Thanks for another thing to put in the ol’ bag o’ tricks.

https://httptoolkit.tech/blog/frida-certificate-pinning/ has a good guide and Frida script that will disable certificate pinning automatically in most cases.

I love you.

Reply on news.ycombinator.com