Graphql Introspection in Feathersjs with Basic Auth

GraphQL introspection is a query capability that allows clients to discover the schema, types, and operations available from a GraphQL endpoint. In FeathersJS, introspection is typically enabled by default during development and can remain accessible in production if the framework configuration does not explicitly disable it. When Basic Auth is used for authentication, the protection relies entirely on the client supplying a valid Authorization header on each request. The combination of an open introspection endpoint and Basic Auth creates a risk where an unauthenticated or low-privileged attacker can enumerate the API schema without needing to know valid credentials.

The vulnerability occurs because introspection queries do not require business-level permissions enforced by FeathersJS services; they are handled at the GraphQL layer before application-level authentication checks are fully applied. If Basic Auth is implemented only on certain routes or via middleware that does not restrict introspection operations, an attacker can issue an introspection query and obtain the full type system, including queries, mutations, subscriptions, and field arguments. This information can reveal sensitive data structures, resolver patterns, and potential attack surfaces such as administrative fields or batch operations.

For example, an attacker can send a POST request with a GraphQL introspection query to a FeathersJS endpoint protected only by Basic Auth. If the Basic Auth credentials are not required for the introspection operation, or if the middleware configuration fails to enforce authentication before the GraphQL resolver pipeline, the schema is returned in clear text. This exposure does not require authentication with a valid user, but it does require the attacker to correctly target the introspection query, which is straightforward given public tooling. The risk is amplified when the API also exposes unauthenticated endpoints or when Basic Auth is inconsistently applied across services, such as being enforced on some FeathersJS hooks but not others.

Using middleBrick to scan such an API can surface this issue under the Authentication and BOLA/IDOR checks, providing a severity rating and remediation steps in the report. Because middleBrick performs black-box testing against the unauthenticated attack surface, it can detect whether introspection is accessible without valid Basic Auth credentials. The scanner does not fix the configuration but supplies prioritized findings with concrete guidance, helping teams align the API with frameworks like OWASP API Top 10 and compliance requirements.

In production, developers should treat introspection as sensitive as any other API operation. Even when Basic Auth is in place, ensure that introspection is disabled or tightly controlled, and verify through scanning and manual review that no unauthorized schema exposure occurs across all configured routes and hooks.

Securing GraphQL introspection in FeathersJS with Basic Auth requires explicit configuration and middleware enforcement. The following examples demonstrate how to disable introspection in production and enforce Basic Auth consistently across GraphQL requests.

First, disable introspection in the FeathersJS GraphQL configuration by setting introspection to false. This prevents schema discovery via standard GraphQL tools while keeping the API functional for known clients.

// src/app.js
const { GraphQLService } = require('@feathersjs/graphql');

app.use('/graphql', new GraphQLService({
  graphQL: {
    schema: mySchema,
    introspection: false,
    rootValue: myResolvers
  },
  authentication: {
    entity: 'users',
    service: 'users',
    header: 'authentication',
    resolver: async (context) => {
      // Custom resolver to validate Basic Auth
      return context.params.headers['authorization'] || null;
    }
  }
}));

Second, implement a FeathersJS hook that validates Basic Auth before allowing any GraphQL operation, including introspection. This ensures that even if introspection is accidentally enabled, access is restricted to authorized users.

// src/hooks/basic-auth.js
const { AuthenticationError } = require('@feathersjs/errors');
const basicAuth = require('basic-auth');

module.exports = function () {
  return async context => {
    const credentials = basicAuth(context.params.headers);
    if (!credentials || credentials.name !== 'admin' || credentials.pass !== 'secret') {
      throw new AuthenticationError('Invalid credentials');
    }
    context.params.user = { role: 'admin' };
    return context;
  };
};

Third, apply the hook globally or specifically to the GraphQL service to enforce authentication on every request:

// src/app.js
app.configure(hooks());
app.use('/graphql', new GraphQLService({
  graphQL: {
    schema: mySchema,
    introspection: true,
    rootValue: myResolvers
  }
}).hooks({
  before: [require('./hooks/basic-auth')]
}));

Finally, verify the configuration using tools like middleBrick. The CLI can be invoked as middlebrick scan <url> to confirm that introspection is no longer publicly accessible and that Basic Auth enforcement is consistent. The dashboard and GitHub Action integrations can be used to track changes over time and fail builds if risky settings are detected.

These steps ensure that GraphQL introspection does not leak schema details and that Basic Auth is applied uniformly, reducing the attack surface exposed through unauthenticated or misconfigured endpoints.