Graphql Introspection in Fiber with Basic Auth
Graphql Introspection in Fiber with Basic Auth — how this specific combination creates or exposes the vulnerability
GraphQL introspection is a feature that allows clients to query the schema structure, types, and operations of a GraphQL endpoint. When an endpoint is built with Fiber and uses Basic Authentication but still exposes introspection queries without restriction, it can unintentionally disclose the full schema to unauthenticated or partially authenticated attackers.
Basic Auth in Fiber typically relies on middleware that checks an Authorization header before allowing access to routes. If introspection is available on the same route without proper access controls, an attacker who knows or guesses the endpoint can send an introspection query and receive a detailed schema response. This can reveal sensitive field names, object relationships, and query patterns that aid in further exploitation.
In a typical Fiber setup, developers may protect routes with Basic Auth middleware but inadvertently leave introspection open, especially during development or when using a default GraphQL handler. Because introspection does not require elevated privileges, the combination of open introspection and Basic Auth protection on other operations creates an inconsistency: authenticated actions are required for some endpoints while the schema itself is freely readable.
An attacker can use introspection to understand how the API models resources and relationships, which can inform targeted attacks such as IDOR or BOLA. Even if Basic Auth guards data-modifying operations, exposing the schema reduces the effort required to craft malicious queries or mutations. This is particularly risky when the schema includes sensitive types or fields that should not be visible to unauthenticated clients.
Using middleBrick, such inconsistencies are detected through unauthenticated scanning that includes GraphQL introspection among its checks. The scanner identifies whether introspection is accessible and maps findings to relevant risks, helping teams understand the exposure without implying any automatic remediation.
Basic Auth-Specific Remediation in Fiber — concrete code fixes
To secure a Fiber GraphQL endpoint with Basic Auth, you should explicitly disable introspection in production or guard it behind the same authentication checks used for other operations. Below are concrete code examples that demonstrate how to implement this securely.
Example 1: Basic Auth middleware protecting all routes including GraphQL
const Fiber = require('fiber');
const { basicAuth } = require('basic-auth');
const app = new Fiber();
const users = {
admin: 'secret123',
};
const basicAuthMiddleware = (req, res, next) => {
const user = basicAuth(req);
if (!user || !users[user.name] || users[user.name] !== user.pass) {
res.set('WWW-Authenticate', 'Basic realm=\"example\"');
return res.status(401).send('Authentication required');
}
next();
};
// Apply Basic Auth to all routes
app.use(basicAuthMiddleware);
// GraphQL endpoint protected by Basic Auth
app.post('/graphql', (req, res) => {
// Your GraphQL handler logic here
res.json({ data: { ok: true } });
});
app.listen(3000, () => console.log('Server running on port 3000'));
Example 2: Disabling introspection explicitly in production
const { graphqlHTTP } = require('express-graphql'); // or a Fiber-compatible GraphQL handler
const schema = require('./schema');
const enableIntrospection = process.env.NODE_ENV !== 'production';
app.post('/graphql', (req, res, next) => {
// Ensure Basic Auth has already been validated by a prior middleware
const allowIntrospection = enableIntrospection;
const graphQLHandler = graphqlHTTP({
schema,
graphiql: false,
customFormatErrorFn: (error) => ({ message: error.message }),
customiseResult: () => ({},
rootValue: null,
validationRules: allowIntrospection ? undefined : [DisableIntrospectionRule],
});
graphQLHandler(req, res, next);
});
Example 3: Conditional introspection based on authentication scope
const introspectionAllowedForRoles = ['admin', 'developer'];
const authMiddlewareWithScopes = (req, res, next) => {
const user = basicAuth(req);
if (!user || !users[user.name] || users[user.name] !== user.pass) {
res.set('WWW-Authenticate', 'Basic realm=\"example\"');
return res.status(401).send('Authentication required');
}
req.userRole = user.name;
next();
};
app.use(authMiddlewareWithScopes);
app.post('/graphql', (req, res) => {
const allowIntrospection = introspectionAllowedForRoles.includes(req.userRole);
const handler = graphqlHTTP({
schema,
graphiql: false,
validationRules: allowIntrospection ? undefined : [DisableIntrospectionRule],
});
handler(req, res);
});
These examples show how to integrate Basic Auth with GraphQL handling in Fiber to reduce the risk of unintended schema exposure. By disabling introspection in production or tightly coupling it to authenticated and authorized contexts, you align the behavior with security best practices.
middleBrick can scan such endpoints to verify whether introspection remains accessible and whether authentication is consistently enforced. Its checks include authentication mechanisms and GraphQL introspection exposure, helping you detect misconfigurations before they are exploited.
Related CWEs: dataExposure
| CWE ID | Name | Severity |
|---|---|---|
| CWE-200 | Exposure of Sensitive Information | HIGH |
| CWE-209 | Error Information Disclosure | MEDIUM |
| CWE-213 | Exposure of Sensitive Information Due to Incompatible Policies | HIGH |
| CWE-215 | Insertion of Sensitive Information Into Debugging Code | MEDIUM |
| CWE-312 | Cleartext Storage of Sensitive Information | HIGH |
| CWE-359 | Exposure of Private Personal Information (PII) | HIGH |
| CWE-522 | Insufficiently Protected Credentials | CRITICAL |
| CWE-532 | Insertion of Sensitive Information into Log File | MEDIUM |
| CWE-538 | Insertion of Sensitive Information into Externally-Accessible File | HIGH |
| CWE-540 | Inclusion of Sensitive Information in Source Code | HIGH |