Graphql Introspection in Fiber
How Graphql Introspection Manifests in Fiber
GraphQL introspection is a powerful feature that allows clients to query the schema of a GraphQL API, but when left exposed in production, it becomes a significant security risk. In Fiber applications, this vulnerability manifests through the default GraphQL configuration that enables introspection without proper controls.
The most common manifestation occurs when developers use the fiber-graphql middleware without disabling introspection in production environments. By default, the introspection query is enabled, allowing any unauthenticated user to retrieve the complete schema definition. This includes all object types, mutations, queries, and even internal fields that should remain hidden from external consumers.
In Fiber applications, introspection typically appears through the following patterns:
router := fiber.New()
gql := fibergraphql.New(
fibergraphql.Config{
Schema: &schema,
// Introspection is enabled by default
},
)
router.Use("/graphql", gql)
Attackers exploit this by sending the standard introspection query:
{
__schema {
types {
name
fields {
name
type { name }
}
}
}
}
This returns the entire schema structure, revealing:
- All available queries and mutations
- Input object structures and required fields
- Enum values and possible options
- Internal types that shouldn't be exposed
- Field arguments and their validation rules
Once attackers have the schema, they can craft targeted attacks against specific mutations or queries, understand the data model completely, and identify potential injection points or authorization bypasses. In Fiber applications, this is particularly dangerous because the schema often contains business logic details that shouldn't be public knowledge.
Fiber-Specific Detection
Detecting GraphQL introspection vulnerabilities in Fiber applications requires both manual testing and automated scanning. The most straightforward detection method is sending an introspection query to your GraphQL endpoint and observing the response.
Manual detection in Fiber:
curl -X POST http://your-fiber-app/graphql \
-H "Content-Type: application/json" \
-d '{"query": "{__schema{types{name}}}"}
If you receive a detailed schema response, introspection is enabled. For more comprehensive detection, you can use middleBrick's automated scanning capabilities, which specifically test for GraphQL introspection vulnerabilities.
middleBrick's GraphQL introspection detection includes:
- Automated introspection query execution against GraphQL endpoints
- Schema analysis to identify exposed types and fields
- Detection of deprecated fields that might indicate legacy or risky functionality
- Analysis of mutation patterns that could indicate data exposure risks
The scanner tests against common GraphQL introspection patterns and provides a risk score based on the completeness of the exposed schema. For Fiber applications specifically, middleBrick can identify when the fiber-graphql middleware is configured without proper introspection controls.
Additional detection methods for Fiber applications:
// Check your GraphQL middleware configuration
if middleware.Config.Introspection == nil || *middleware.Config.Introspection {
fmt.Println("Introspection is enabled")
}
You can also inspect the Fiber application's GraphQL middleware setup to verify whether introspection is properly configured for production environments.
Fiber-Specific Remediation
Remediating GraphQL introspection vulnerabilities in Fiber applications requires a multi-layered approach. The primary solution is to disable introspection in production while maintaining it for development and testing environments.
Environment-based configuration in Fiber:
router := fiber.New()
// Enable introspection only in development
gql := fibergraphql.New(
fibergraphql.Config{
Schema: &schema,
Introspection: util.GetEnv("GO_ENV", "development") == "development",
},
)
router.Use("/graphql", gql)
For more granular control, you can implement custom middleware that checks authentication and environment before allowing introspection queries:
func graphqlHandler(schema *graphql.Schema) fiber.Handler {
return func(c *fiber.Ctx) error {
// Check if request is an introspection query
if isIntrospectionQuery(c) {
// Only allow if authenticated and in dev
if c.Locals("user") == nil || os.Getenv("GO_ENV") != "development" {
return c.Status(fiber.StatusForbidden).JSON(fiber.Map{
"error": "Introspection disabled",
})
}
}
return fibergraphql.Do(c, schema)
}
}
func isIntrospectionQuery(c *fiber.Ctx) bool {
var req map[string]interface{}
if err := c.BodyParser(&req); err != nil {
return false
}
query, ok := req["query"].(string)
if !ok {
return false
}
return strings.Contains(strings.ToLower(query), "__schema") ||
strings.Contains(strings.ToLower(query), "__type")
}
Another effective approach is implementing schema whitelisting for production:
func filteredSchema(schema *graphql.Schema) *graphql.Schema {
return graphql.NewSchema(graphql.SchemaConfig{
Query: filteredQueryType(schema.Query),
Mutation: filteredMutationType(schema.Mutation),
// Other types filtered similarly
})
}
func filteredQueryType(original graphql.Type) graphql.Type {
// Create a new object type that only exposes safe fields
return graphql.NewObject(graphql.ObjectConfig{
Name: "Query",
Fields: filterFields(original, safeFields),
})
}
For Fiber applications using the fiber-graphql package, you can also leverage its built-in configuration options:
gql := fibergraphql.New(
fibergraphql.Config{
Schema: &schema,
Introspection: false, // Disable in all environments
// Alternative: use environment variable
// Introspection: os.Getenv("ENABLE_INTROSPECTION") == "true",
},
)
Testing your remediation is crucial. After implementing changes, use middleBrick to verify that introspection is properly disabled and that your GraphQL endpoint maintains full functionality for legitimate clients.
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 |