Hi!
How can I disable introspection in Absinthe/GraphQL?
I would like the GraphQL API to respond only to defined queries and mutations, but not allow client to list schema and types, because of security reasons (Wheter it makes sense or is security through obscurity is another issue, the requirement is not my idea).
I understand that for introspection, also GraphQL is used on fields __schema and __type.
It seems that I should be able to filter them with middleware (return :error??), but I am not sure how to add a middleware a top-level / built in queries like these.
Perhaps there is a different approach to achieve this?
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?
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!
but people are gonna do it anyway, so itâs best we try educate rather than block.
Sorry, I mean in terms of communication
I am having the same issue, quite honestly I donât understand why they want it either.
