Graphql Introspection in Echo Go with Hmac Signatures

GraphQL introspection allows clients to query the schema structure, types, and operations of a GraphQL endpoint. In an Echo Go service that uses HMAC signatures for request authentication, enabling introspection without restrictions can expose the full API surface to unauthenticated or partially authenticated attackers. Even when HMAC signatures protect specific mutation or query endpoints, introspection queries are often allowed through the same route, bypassing signature validation if the middleware does not explicitly apply to GraphQL introspection operations.

Consider an Echo Go route mounted at /graphql with middleware that validates HMAC signatures for standard HTTP requests. If the GraphQL handler does not gate introspection behind the same signature check, an attacker can send an introspection query to /graphql without a valid HMAC. Because introspection returns the full schema — including query and mutation field names, argument types, and resolver configurations — the attacker gains detailed knowledge that facilitates targeted attacks such as BOLA/IDOR or input validation exploitation. This becomes particularly risky when combined with overly permissive CORS policies or when the HMAC implementation does not enforce scope or role constraints on the introspection path.

Real-world patterns show that introspection responses can include sensitive field names like resetPassword or internalAdminToken, which may hint at privileged operations. If the HMAC validation logic only checks a subset of routes or headers, attackers can craft introspection requests that appear valid but lack the required signature. This exposes the attack surface without triggering alerts, as the requests technically reach the GraphQL layer. Insecure default configurations in some Echo Go GraphQL libraries can further exacerbate this by enabling introspection in production, especially if developers assume HMAC coverage is universal.

Additionally, attackers can combine introspection with malicious queries to probe for rate-limiting gaps or data exposure paths. For example, nested introspection fragments can be used to map relationships between types, revealing indirect endpoints that may lack proper authorization. When HMAC signatures are tied to specific user roles but introspection is not role-aware, the schema itself becomes a leakage channel. This highlights the need to treat introspection as a first-class operation in the security model, aligned with the same controls as other GraphQL requests, including signature validation and output filtering.

To secure GraphQL introspection in Echo Go alongside HMAC signatures, ensure that introspection is either disabled in production or explicitly protected by the same signature validation applied to other endpoints. Below is a concrete example of how to implement HMAC verification in Echo Go and conditionally allow introspection only when the signature is valid and the requestor has appropriate permissions.

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
    "net/http"
    "strings"

    "github.com/labstack/echo/v4"
)

func isValidHMAC(payload, receivedMAC, secret string) bool {
    key := []byte(secret)
    mac := hmac.New(sha256.New, key)
    mac.Write([]byte(payload))
    expectedMAC := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(expectedMAC), []byte(receivedMAC))
}

func HMACMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        rawBody := c.Request().Body
        // In practice, read and restore body if needed for logging
        payload := c.Param("ignored") // placeholder example
        receivedMAC := c.Request().Header.Get("X-HMAC-Signature")
        secret := "your-256-bit-secret"

        if !isValidHMAC(payload, receivedMAC, secret) {
            return c.JSON(http.StatusUnauthorized, map[string]string{
                "error": "invalid hmac signature",
            })
        }
        return next(c)
    }
}

func main() {
    e := echo.New()

    // Apply HMAC middleware to all routes including GraphQL
    e.Use(HMACMiddleware)

    e.POST("/graphql", func(c echo.Context) error {
        var req struct {
            Query string `json:"query"`
        }
        if err := c.Bind(&req); err != nil {
            return c.JSON(http.StatusBadRequest, map[string]string{
                "error": "invalid request",
            })
        }

        // Disable introspection in production by default
        if strings.Contains(req.Query, "__schema") || strings.Contains(req.Query, "__type") {
            return c.JSON(http.StatusForbidden, map[string]string{
                "error": "introspection not allowed",
            })
        }

        // Proceed with execution
        return c.JSON(http.StatusOK, map[string]string{
            "data": "executed",
        })
    })

    e.Logger().Fatal(e.Start(":8080"))
}

In this example, HMAC validation runs before the GraphQL handler, ensuring that introspection queries must carry a valid signature. To further reduce risk, you can conditionally allow introspection only for specific roles or internal services by inspecting additional headers or JWT claims within the middleware. Combining this with schema directives to disable introspection at the resolver level provides defense in depth.

For continuous protection, integrate the scan command using the CLI: middlebrick scan <url>, which can detect whether introspection is exposed and whether HMAC coverage is inconsistent across endpoints. In collaborative environments, use the GitHub Action to fail builds if the risk score indicates that introspection remains publicly accessible. Teams using the Web Dashboard can track changes in exposure over time, while the MCP Server enables AI coding assistants to flag insecure introspection configurations during development.