Graphql Introspection in Aspnet with Basic Auth

GraphQL introspection in an ASP.NET endpoint combined with Basic Authentication creates a risk where an unauthenticated or partially authenticated attacker can discover the full schema, types, queries, and operations available to the application. Even when Basic Auth is present, misconfiguration or inconsistent enforcement can allow introspection queries to succeed without valid credentials, effectively bypassing intended access controls.

In ASP.NET, GraphQL servers (e.g., using GraphQL.Server or HotChocolate) often expose a GraphQL endpoint such as /graphql. If introspection is enabled and the endpoint does not properly validate credentials before resolving introspection operations, an attacker can send an introspection query over HTTP using only Basic Auth credentials that are either missing, empty, or accepted with a default fallback. Because Basic Auth transmits base64-encoded credentials in headers, an absent or weak Authorization header may still be treated as valid by permissive middleware, allowing introspection to proceed.

This becomes a dangerous information leak because the schema reveals sensitive data structures, query capabilities, and potential business logic. When paired with other unchecked attack surfaces (e.g., missing rate limiting or input validation), an attacker can enumerate operations, test for BOLA/IDOR patterns, or prepare targeted injection attempts. In a black-box scan by middleBrick, such a configuration would contribute to a finding under Authentication and BOLA/IDOR checks, and would lower the security score due to exposed schema details that facilitate further exploitation.

For example, a curl command lacking proper credentials but reaching an endpoint with relaxed CORS or middleware rules may still receive a 200 response with schema data:

curl -X POST https://api.example.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __schema { queryType { name } } }"}'

middleBrick’s checks for Authentication and BOLA/IDOR would flag this if introspection is reachable without valid, scoped credentials. The scan would also flag Data Exposure and Unsafe Consumption findings if the schema reveals sensitive fields or if responses contain PII. Enabling strict schema controls and ensuring authentication gates introspection are essential steps to reduce the attack surface.

To secure GraphQL introspection in ASP.NET when using Basic Authentication, enforce credential validation before allowing introspection operations. This involves configuring authentication middleware to reject unauthenticated requests and explicitly disabling introspection for unauthorized contexts.

Below are concrete code examples for disabling introspection when no valid Basic Auth header is present, and for allowing introspection only for specific roles or clients when credentials are valid.

Example 1: Disable introspection when credentials are missing

In Startup.cs or Program.cs, configure the GraphQL endpoint to require authentication and to skip introspection when credentials are absent:

// Program.cs (ASP.NET 6+)
builder.Services.AddAuthentication("BasicAuthentication")
    .AddScheme("BasicAuthentication", null);
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAuthenticatedSchema", policy =>
        policy.RequireAuthenticatedUser());
});

app.UseAuthentication();
app.UseAuthorization();

app.UseEndpoints(endpoints =>
{
    endpoints.MapGraphQL("/graphql")
        .RequireAuthorization()
        .WithOptions(options =>
        {
            options.Schema = /* your schema */;
            options.EnableMetrics = false;
            // Disable introspection unless explicitly allowed
            options.EnableIntrospection = false;
        });
});

Example 2: Allow introspection only for authorized users with a custom policy

For environments where introspection is needed in specific contexts (e.g., internal tools), use a policy-based approach that checks roles or a custom header:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("IntrospectionAllowed", policy =>
        policy.RequireAssertion(context =>
        {
            var authHeader = context.Resource?.GetType().GetProperty("Headers")?.GetValue(context.Resource) as IHeaderDictionary;
            if (authHeader?.TryGetValue("Authorization", out var headerValues) == true)
            {
                var token = headerValues.ToString().Replace("Basic ", "");
                var credential = Encoding.UTF8.GetString(Convert.FromBase64String(token));
                var parts = credential.Split(':');
                if (parts.Length == 2 && parts[0] == "admin" && parts[1] == "secret")
                {
                    return true;
                }
            }
            return false;
        }));
});

app.UseEndpoints(endpoints =>
{
    endpoints.MapGraphQL("/graphql")
        .RequireAuthorization("IntrospectionAllowed")
        .WithOptions(options =>
        {
            options.Schema = /* your schema */;
            options.EnableIntrospection = true; // Allowed only by policy
        });
});

These examples ensure that introspection is not available by default and is gated behind explicit authentication and authorization checks. When combined with other security practices such as input validation, rate limiting, and transport encryption, the risk of schema enumeration via introspection is significantly reduced.

middleBrick’s scans will reflect improved security posture when introspection is properly restricted, showing better scores under Authentication, Data Exposure, and BOLA/IDOR categories. For ongoing protection, consider the Pro plan to enable continuous monitoring and CI/CD integration that fails builds if risky configurations are detected.