Remove section on disabling GraphQL introspection

[aspett]

Disabling introspection on GraphQL should be considered an anti-pattern because

• It is security through obscurity
• Breaks a significant feature of GraphQL

While many developers reach for it based on previous experiences of not exposing documentation to the public, it has been well established in the Elixir community for a long time that it is not recommended. I'd suggest reaching out in the Elixir slack #absinthe-graphql for further discussion. Unfortunately the chat history is long lost, but sentiment likely remains.

I understand this is a subjective opinion, but I think it's pretty controversial overall to include this section.

[houllette]

I'd love to have a discussion about it's inclusion / exclusion:

While the intention of this section isn't fully clear yet due to a WIP adjustment, the idea with this section is to outline that we believe GraphQL Introspection should be disabled on Production systems and optionally allow for it in Development environments. Additionally, one could allow for the bypassing of this filtering on Production via mechanisms like SimpleTokenAuth.

Here is a related blog post from Apollo on why they believe Introspection should be disabled. Additionally, OWASP outlines disablement as a Secure Configuration Best Practice on their "cheat sheet" series.

Due to the above reasons I would lean towards leaving it as is in the training material, but it would definitely be worth considering adding additional clarification to the lesson that by itself it is not an all encompassing protection and fully outline the "protections" that disabling introspection affords.

[aspett]

Thanks for the reply Holden.

The OWASP page is good 👍 - Glad both pages mention that this is security by obscurity. Protecting introspection by authorization is a nicer middle ground than completely disabling it.

It would be great to discuss these nuances rather than blanket suggesting disabling it.

Cheers!