Graphql Introspection in Echo Go
How Graphql Introspection Manifests in Echo Go
GraphQL introspection is a powerful feature that allows clients to query an API's schema to discover available types, fields, and operations. In Echo Go applications, this manifests when developers expose GraphQL endpoints without proper introspection controls, creating a roadmap for attackers to understand the complete API surface before launching targeted attacks.
In Echo Go, GraphQL introspection typically appears in two vulnerable patterns. First, when using libraries like 99designs/gqlgen or vektah/gqlparser without configuring the DisableIntrospection option, the server exposes the full schema through the standard __schema query. Second, when developers implement custom GraphQL handlers in Echo without rate limiting or authentication middleware, allowing unrestricted schema discovery.
The vulnerability becomes particularly dangerous in Echo Go applications because attackers can use introspection to map out complex relationships between types, identify sensitive fields like password, ssn, or creditCard, and discover mutation operations that might not be documented. For example, an attacker could run:
query IntrospectionQuery {
__schema {
types {
name
fields {
name
type {
name
kind
}
}
}
}
}
This query returns the complete type system, allowing attackers to craft precise queries targeting vulnerable fields or operations that weren't intended for public consumption.
In Echo Go applications, this often combines with other issues like missing authentication middleware on GraphQL endpoints, creating a perfect storm where attackers can both discover the schema and execute arbitrary queries without authorization checks.
Echo Go-Specific Detection
Detecting GraphQL introspection vulnerabilities in Echo Go requires both manual testing and automated scanning. The most straightforward detection method is to send an introspection query to your GraphQL endpoint and observe the response. Using curl:
curl -X POST \
-H "Content-Type: application/json" \
-d '{"query":"query IntrospectionQuery { __schema { types { name } } }"}' \
http://your-echo-app/graphql
If this returns a comprehensive list of types without authentication, your Echo Go application has an introspection vulnerability.
For automated detection, middleBrick's GraphQL security scanner specifically targets Echo Go applications by testing the introspection endpoint with multiple query patterns. The scanner checks for:
- Standard introspection queries that return full schema information
- Rate limiting bypass attempts on introspection endpoints
- Authentication bypass through GraphQL introspection
- Excessive data exposure through schema queries
middleBrick's LLM/AI security module also scans for AI-specific GraphQL vulnerabilities, testing for prompt injection patterns in AI-powered GraphQL resolvers that might be present in Echo Go applications using AI services.
Additional detection techniques include examining your Echo Go GraphQL handler registration. Look for patterns like:
e.POST("/graphql", graphqlHandler)
Without proper middleware configuration. The scanner also checks for missing DisableIntrospection: true configuration in gqlgen setups, which is a common oversight in Echo Go applications.
Echo Go-Specific Remediation
Remediating GraphQL introspection vulnerabilities in Echo Go requires a layered approach. The most effective solution combines configuration changes with middleware protection. For applications using gqlgen with Echo, implement introspection disabling:
package main
import (
"github.com/99designs/gqlgen/graphql/handler"
"github.com/99designs/gqlgen/graphql/introspection"
"github.com/labstack/echo/v4"
)
func main() {
e := echo.New()
cfg := Config {
DisableIntrospection: true, // Disable introspection by default
}
s := handler.NewDefaultServer(NewExecutableSchema(cfg))
// Optional: Re-enable for authenticated users only
e.POST("/graphql", func(c echo.Context) error {
if !isAuthenticated(c) {
return echo.ErrUnauthorized
}
// Enable introspection for authorized users
s.AroundFields(func(ctx context.Context, next graphql.Resolver) (interface{}, error) {
return next(ctx)
})
return s.ServeGraphQL(c.Response().Writer, c.Request())
})
}
For Echo Go applications using custom GraphQL handlers, implement middleware-based protection:
package main
import (
"github.com/labstack/echo/v4"
"github.com/labstack/echo/v4/middleware"
)
func graphqlMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
return func(c echo.Context) error {
// Check for introspection queries
if c.Request().Method == "POST" {
var req map[string]interface{}
if err := json.NewDecoder(c.Request().Body).Decode(&req); err != nil {
return next(c)
}
if query, ok := req["query"].(string); ok {
// Block introspection queries
if strings.Contains(strings.ToLower(query), "__schema") ||
strings.Contains(strings.ToLower(query), "__type") {
return c.JSON(http.StatusBadRequest, map[string]string{
"error": "Introspection queries are not allowed",
})
}
}
}
return next(c)
}
}
func main() {
e := echo.New()
e.Use(middleware.Logger())
e.Use(middleware.Recover())
// Apply GraphQL middleware to the endpoint
e.POST("/graphql", graphqlMiddleware(graphqlHandler))
e.Logger.Fatal(e.Start(":1323"))
}
Additional remediation steps include implementing rate limiting on GraphQL endpoints using Echo's middleware:
e.Use(middleware.RateLimiterWithConfig(middleware.RateLimiterConfig{
Store: middleware.RateLimiterRedisConfig{
KeyPrefix: "graphql",
Address: "redis:6379",
},
Max: 100,
TimeWindow: 1 * time.Hour,
SkipFailedRequests: true,
SkipSuccessfulRequests: false,
}))
For production Echo Go applications, consider implementing a GraphQL allowlist that only permits specific, pre-approved queries rather than allowing arbitrary client-defined queries. This approach, combined with disabled introspection, provides the strongest protection against GraphQL-based attacks.
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 |