How to disable Absinthe GraphQL introspection

I also would like to achieve this.

I cannot make Absinthe do document validation after authentication.

We resolved this by middleware on a Plug level. If parameter query contains "__schema" on production servers then we reply with 403.
About 6 months ago I’ve asked this question in Slack and I saved the discussion

shanesveller [6:27 PM]
now that you have the “how” it might be a good time to talk about the “why”, and how a lot of folks feel that it is counterproductive to deny introspection requests
dpehrson [6:27 PM]
I’ve yet to understand why so many people want to hide their introspection.
shanesveller [6:27 PM]
particularly if it is part of an effort to improve security
dpehrson [6:27 PM]
But it seems pretty popular.
[6:28 PM] If you’re trying to hide the API, it seems like you should just put it behind some sort of secondary auth.
[6:28 PM] Like one credential just to access the endpoint, and separate credentials for client auth.
Today
aspett [12:35 AM]
Plenty of companies do not publish documentation for their APIs and endpoints, or at least put it behind their authentication - without relying on this for security. I don’t see why GraphQL should be any different.
shanesveller [12:37 AM]
documentation is an overlapping but separate idea from introspection, though - a lot of client libs rely on the latter for codegen or at runtime, and some of those latter can’t be satisfied by a local dev environment
aspett [12:39 AM]
So? If someone wants to totally hide introspection, then that’s the tradeoff they make.
shanesveller [12:39 AM]
feels like missing the point a bit. ¯_(ツ)_/¯
[12:39 AM] not that you are, but that someone who desires to ignore that aspect is
aspett [12:40 AM]
I hope that most people are actually asking because they want to put it behind auth, rather than totally turning it off - we might consider doing that for our graphs.
benwilson512 [12:42 AM]
people are asking to have it pruned from the schema entirely
aspett [12:43 AM]
:man-shrugging: Oh well. That’s weird, but we should be explaining the reasoning and tradeoff rather than so harshly telling people they’re wrong which I’ve seen in past
benwilson512 [1:13 AM]
@aspett I think the issue is that introspection is built into the spec
[1:13 AM] it is, as far as I can tell, not considered optional
dpehrson [1:39 AM]
My feeling is that they are reaching for the wrong solution to something that likely isn’t actually a problem.
[1:39 AM] But, at the end of the day, everyone gets to chart their own course.
aspett [1:44 AM]
There are plenty of people doing it on other frameworks quite easily, so despite introspection being in the spec and disabling it probably being the wrong solution, it seems not uncommon to do so. Again, I agree with you both but people are gonna do it anyway, so it’s best we try educate rather than block.
benwilson512 [2:01 AM]
@aspett worth noting that Absinthe’s stance was never to block people, it just wasn’t really possible to do anything about it until recently (edited)
[2:01 AM] Absinthe 1.5 allows people to, amongst other things, edit the built in types
[2:02 AM] and so now I’m happy to educate and discuss, but previously there wasn’t a ton that could be done
aspett [2:02 AM]
Sorry, I mean in terms of communication
benwilson512 [2:02 AM]
yup. I think we’re on the same page at this point

fuelen [5:27 PM]
we use absinthe for private api, developers don’t work on production servers during development, so they can grab schema from other servers and codegen is not an issue. Infosec said to hide graphiql and ability to inspect schema using other clients and I’m looking for easy way to do this. That’s all
aspett
:man-shrugging: Oh well. That’s weird, but we should be explaining the reasoning and tradeoff rather than so harshly telling people they’re wrong which I’ve seen in past
dpehrson [5:28 PM]
As a person who cares about infosec greatly, that still makes no sense to me.
[5:28 PM] ¯_(ツ)_/¯
[5:29 PM] It’s not wrong, it’s just….odd.
[5:31 PM] From pure game theory, any information leak is technically bad, but practically, if exposing the types/fields of an API schema is a security risk, there seem to be much bigger problems at play. (edited)
[5:31 PM] At that point, the endpoint should be fully protected from unrecognized clients.

We resolved this by middleware on a Plug level. If parameter query contains “__schema” on production servers then we reply with 403.

@fuelen so you literally check for substring __schema in query, or did you do some parsing? If I post a comment about “__schema” in a legitimate addComment() mutation, will this also return 403?

Yes, just String.contains?(query, "__schema")

Yes and no.
Yes if parameters are inlined into query. No if parameters are passed separately.

Was that Google Review team who strongly suggested you disable introspection? I am having the same issue, quite honestly I don’t understand why they want it either.

No, that was a penetration testing company that reviewed our app. We needed this because we are providing service for a public institution.
Overall they had a lot of good comments/tips!

I wonder if that wasn’t the same company. Over all they were very good (surprising!) but this one requirement was kinda bummer.

I went with a similar approach to @fuelen to disable introspection completely or based on some context (e.g an authorized client, codegen tool, etc), this is a simple solution using an Absinthe plugin: Disable GraphQL schema introspection in Elixir Absinthe · GitHub