A GraphQL Federation directive for Subgraph-level compliance: @openfed__requireFetchReasons
Jens Neuse
Most people don’t see @requires as a problem, but it’s a real compliance risk. With @openfed__requireFetchReasons, subgraphs know exactly why a field is being fetched and can allow or deny access based on clear rules. Sensitive fields like minimumPrice stay under control, audits get easier, and compliance becomes declarative.
You've probably never heard of this before, and you might not even see it as a problem. But the @requires directive is a serious security and compliance risk.
Typically, you might be thinking that "attacks" come from the outside. With security and compliance, we have to carefully think about the architecture we're building. In GraphQL Federation , subgraphs can leak information to other subgraphs through the @requires directive.
We're introducing the @openfed__requireFetchReasons directive to address this problem. It lets subgraph owners define an allowlist of subgraphs that can access to a sensitive field. For organizations that must comply with strict security and data governance regulations, this directive is a key step toward passing audits.
Let’s look at an example to see how this works. In our fictional case, we have a company called LeeWay that lets users auction off their old, useless, proprietary software. We use two subgraphs to implement the auction functionality. Access to the “minimum price” is sensitive, since an attacker could exploit it to win an auction for almost nothing.
Imagine you're a CTO that bought Apollo GraphOS two years ago. You realize WunderGraph Cosmo is not only a better product—more capable and faster than Apollo—but also open source and far less restrictive. So you decide to dump Apollo and auction your GraphOS license to the highest bidder.
An attacker could extend the auction type with an unsuspicious looking field that @requires the minimumPrice field. This way, someone outside auction team could still gain access to it.
From a compliance point of view, everyone thought the minimumPrice field was only available to the auction service team. Security controls were put in place to ensure no staff member outside that team could access it. The compliance team might not understand how @requires works, so they believe everything is safe while the minimumPrice field remains exposed to other subgraphs.
To illustrate the problem, here are the schema definitions for the two subgraphs.
If a client queries the description field, the Router will fetch minimumPrice from the Auction subgraph. It then passes this value as part of the entity representation to the Description subgraph:
The minimumPrice field can be fetched by a client at any time. This post is not about authorization but about compliance. Authorization is still needed to make sure only the auction creator can see the minimumPrice field. Here, the focus is on making sure a sensitive field is not exposed to another subgraph without explicit consent.
To solve the problem, we're introducing the @openfed__requireFetchReasons directive. We'll apply it to the minimumPrice field in the Auction Subgraph to see how it works.
With the directive applied, the Router’s request to the Auction subgraph will include the fetch reasons for the minimumPrice field. These appear in the extensions field:
The Auction Subgraph can now parse the fetch reasons and use an allowlist to decide whether or not the minimumPrice field can be fetched. To accurately distinguish between the different fetch reasons, we're also adding a by_user field to the fetch reasons.
Let's assume that the Description Subgraph doesn't use the @requires directive. If the user requests the minimumPrice field, the request would look like this:
As you can see, the by_user field is set to true, which makes it easy to tell this fetch reason apart. In this case, we would not deny the request, but we'd still need to check authorization in another step.
We're very customer focused at WunderGraph and committed to solving advanced compliance and security challenges. With the @openfed__requireFetchReasons directive, we’re not only addressing a real problem but also raising compliance to a new level.
In a classic microservice architecture, it’s often difficult or even impossible to understand dependencies between services. This makes it hard to detect security and compliance issues like the one in this post.
With Federation and the @openfed__requireFetchReasons directive, we're turning a compliance nightmare into a declarative problem. Put the directive on sensitive fields and manage an allowlist of services that can fetch them.
If you're not yet using GraphQL Federation and you're thinking about compliance, this could be the missing piece to easily pass audits. Instead of manually auditing every service, you can now declaratively define dependencies and compliance rules in your schema.
Frequently Asked Questions (FAQ)
It can leak sensitive information from one subgraph to another, even if compliance controls assume the field is restricted. For example, an attacker could use `@requires` to access the `minimumPrice` field in an auction system.
It attaches fetch reasons to router requests. Subgraphs can parse these reasons and use an allowlist to decide whether a sensitive field, like `minimumPrice`, should be returned.
The `by_user` field in fetch reasons distinguishes between user-initiated requests and subgraph-initiated ones. This helps subgraphs tell different fetch reasons apart and apply the right controls.
No. Authorization is still required to ensure, for example, that only the auction creator can see the `minimumPrice`. The directive addresses compliance and cross-subgraph access, not per-user access control.
Instead of manually auditing every service in a microservice architecture, organizations can define dependencies and compliance rules directly in the schema. This makes sensitive data access explicit, declarative, and auditable.
It’s a GraphQL Federation directive that adds fetch reasons to router requests, allowing subgraphs to enforce compliance and security rules on sensitive fields.
Jens Neuse
CEO & Co-Founder at WunderGraph
Jens Neuse is the CEO and one of the co-founders of WunderGraph, where he builds scalable API infrastructure with a focus on federation and AI-native workflows. Formerly an engineer at Tyk Technologies, he created graphql-go-tools, now widely used in the open source community. Jens designed the original WunderGraph SDK and led its evolution into Cosmo, an open-source federation platform adopted by global enterprises. He writes about systems design, organizational structure, and how Conway's Law shapes API architecture.
