As discussed in our last post, How Secure is Your GraphQL Server?, inconsistencies in GraphQL implementations are common among the different GraphQL offerings.
Let’s take a closer look at how granular access control can help protect from weaknesses around schema fetching.
Introspection, field suggestions, and field fuzzing play a significant role in equipping abusers with information on their target’s functionality by allowing insecure data mapping and sensitive information disclosure.
For many developers, the common practice is to disable Introspection – the first topic you come across when researching methods to secure your GraphQL. As a result, the discoverability nature of the feature will be lost. Those who choose to keep Introspection open are left with an “all-or-nothing” dilemma, exposing sections of the schema to users who don’t have access.
The vast majority of GraphQL implementations don’t offer developers control for field suggestions, which allows abusers to quickly map the schema using field fuzzing even when Introspection is disabled. Supplying incorrect fields will trigger GraphQL to disclose fields with similar names.
If you are looking for an approach that can both limit the visibility of the schema and allow your users to explore it, consider role-based granular access control.
Inigo allows developers to configure edge-based access control, resulting in a different Introspection experience per role while still maintaining one schema. Based on their role, users will only be exposed to the types and fields they have access to.
With Inigo’s granular Introspection access control, field suggestions are disabled while only approved fields are visible via Introspection per role – regardless of the specific GraphQL server implementation. As a result, multiple variations of Schema Fetching are prevented, allowing you to feel more confident in the security of your GraphQL server.
Ready to defend against GraphQL server attacks? Inigo can help! Schedule a demo now.
Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.
Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.