Do You Need CORS in GraphQL?

If you’re exposing a GraphQL endpoint—whether a single schema or a federated supergraph—someone on your team is eventually going to ask: Do we need to configure CORS?

The answer is: yes, but only where it matters. And if you’re running a federated setup with HotChocolate Fusion, it’s worth understanding exactly where that boundary is.

The architecture we have at my current work, is that we run multiple subgraphs inside a secured AKS environment, behind an internal network where only the Fusion Supergraph is publicly accessible (via an ingress).

Subgraphs are not reachable from the public internet. They only serve the Supergraph through server-to-server communication.

This is important.

Let’s back up and look at what CORS actually does.

CORS (Cross-Origin Resource Sharing) is a browser-side security mechanism. It tells the browser which origins are allowed to make cross-origin HTTP requests to your backend.

This is enforced only in the browser.

• Servers calling each other don’t care about CORS.

• It’s not a network firewall.

• It’s not auth.

• It’s a browser rule!

So do SUB-graphs Need CORS?

• ❌ No. Subgraphs don’t need CORS if they are only suposed to be accessed by the Fusion Supergraph.
• ✅ Yes, if they are publicly accessible and you want to allow cross-origin requests from a browser.

Resons for NO:

• They’re not accessed directly by a browser.
• They’re behind the firewall (inside AKS). That is if you’re using AKS.
• Fusion accesses them server-to-server—CORS does not apply in this context.

So does the Fusion SUPER-graph Need CORS?

✅ Yes, if your frontend accesses the Supergraph from a different origin.

Example Scenario

• Frontend: https://myfrontend.com
• Supergraph: https://graphql.mydomain.com
• Subgraph(s): https://user.mydomain.com, https://orders.mydomain.com

✅ Supergraph needs CORS to allow requests from https://myfrontend.com

❌ Subgraphs do not need CORS because the frontend does not access them directly

The browser sees this as a cross-origin request. If the Supergraph doesn’t have CORS enabled, the browser will block it—regardless of whether the API itself is publicly reachable.

If you want your frontend to work, you need to enable CORS on the Supergraph.

Here is the CORS configuration for the Supergraph:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowFrontend",
        policy => policy.WithOrigins("https://myfrontend.com")
                        .AllowAnyHeader()
                        .AllowAnyMethod());
});

var app = builder.Build();

app.UseCors("AllowFrontend");
app.UseRouting();
app.UseEndpoints(endpoints =>
{
    endpoints.MapGraphQL();
});

app.Run();

What if every web url should be to access the Supergraph?

If your goal is to let anyone call your GraphQL Supergraph (public docs, open data, etc.), you can allow all origins:

policy
    .AllowAnyOrigin()
    .AllowAnyHeader()
    .AllowAnyMethod();

Just know the tradeoffs—this means any website can query your API from the browser.

Make sure you’ve got rate limiting, abuse detection, and proper auth in place.

Who Needs CORS?

Lets recap and see what needs CORS:

Make CORS decisions based on where and how your clients access the graph based on blanket assumptions. If it’s not a browser hitting the endpoint, it probably doesn’t need CORS.