Graphql Introspection in Echo Go with Cockroachdb

GraphQL introspection allows clients to query the schema for types, queries, and mutations. In an Echo Go service that connects to Cockroachdb, enabling introspection in production exposes the full structure of your GraphQL API and, indirectly, the database shape your resolvers interact with. This combination becomes risky when introspection is left available without authentication, because an unauthenticated attacker can retrieve field names, input types, and query patterns that reveal how data is modeled in Cockroachdb.

Echo Go does not enable introspection by default in production builds, but if you mount a GraphQL handler without disabling introspection, the endpoint will respond to __schema and __type queries. Because Cockroachdb is often the backend data store, the returned schema can hint at table names, column types, and relationship patterns that may not be intended for client exposure. When combined with other unchecked attack surfaces—such as missing authentication on certain queries or mutations—this information can aid in crafting further attacks like BOLA/IDOR or Property Authorization issues.

The risk is not that introspection directly leaks Cockroachdb credentials; rather, it is the metadata leakage that compounds existing weaknesses. For example, if your GraphQL types mirror Cockroachdb table columns exactly, an attacker learns column names and types that could be used in injection or data exfiltration steps. With the middleware stack in Echo Go, if introspection is reachable without rate limiting or proper access controls, the unauthenticated attack surface identified by middleBrick’s Authentication and BOLA/IDOR checks becomes larger and easier to probe.

Using tools like middleBrick, this specific combination can be scanned to detect whether introspection is accessible, whether the GraphQL endpoint reveals schema details, and whether unauthenticated probes expose data exposure risks tied to your Cockroachdb-driven resolvers. The scanner runs checks such as Data Exposure and Authentication in parallel, highlighting whether introspection responses include sensitive field descriptions or examples that should not be public.

To secure the Echo Go + GraphQL + Cockroachdb stack, disable introspection in production and ensure your resolvers do not expose metadata that maps 1:1 to database objects. Below are concrete code examples that show how to configure introspection and structure resolvers safely.

Disabling introspection in production

When creating the GraphQL server in your Echo Go application, configure the playground and introspection options based on the environment. In production, disable both the playground and introspection.

import (
    "github.com/labstack/echo/v4"
    "github.com/hasura/graphql-go"
    "github.com/hasura/graphql-go/relay"
)

func NewGraphQLServer(e *echo.Echo, isProd bool) {
    schema := graphql.MustParseSchema(`
        type Query {
            user(id: ID!): User
            users: [User]
        }
        type User {
            id: ID!
            name: String!
            email: String!
        }
        schema {
            query: Query
        }
    `, &graphql.SchemaConfig{
        Resolvers: &resolver{},
    })

    opts := []graphql.ServerOpt{
        graphql.PlaygroundDisabled(!isProd),
        graphql.IntrospectionDisabled(isProd),
    }
    h := graphql.New(schema, opts...)
    e.POST("/graphql", func(c echo.Context) error {
        return h.ServeHTTP(c.Response(), c.Request())
    })
}

Parameterized queries with Cockroachdb to avoid injection and metadata leakage

Ensure your resolver methods use parameterized SQL queries against Cockroachdb instead of string concatenation. This prevents injection and avoids dynamic schema probing via error messages that could reveal table or column names.

import (
    "context"
    "database/sql"
    _ "github.com/cockroachdb/cockroach-go/v2/crdb"
)

type resolver struct{ db *sql.DB }

func (r *resolver) User(ctx context.Context, id string) (*User, error) {
    var u User
    // Use parameterized query; Cockroachdb requires placeholders like $1
    err := r.db.QueryRowContext(ctx, "SELECT id, name, email FROM users WHERE id = $1", id).Scan(&u.ID, &u.Name, &u.Email)
    if err != nil {
        if err == sql.ErrNoRows {
            return nil, nil
        }
        return nil, err
    }
    return &u, nil
}

Schema-first design with limited exposure

Define your GraphQL types explicitly and avoid automatic struct embedding that could expose internal Cockroachdb column names or tags. Map resolver fields deliberately to avoid leaking implementation details.

type User struct {
    ID    string
    Name  string
    Email string
}

// Do not expose internal struct tags that mirror Cockroachdb columns directly
// Instead, use explicit resolvers to shape output.

Complementary runtime checks

Use middleBrick to verify that introspection is disabled in production, that no unauthenticated queries expose schema details, and that Data Exposure checks do not flag your GraphQL endpoint. The CLI scan can be integrated into development workflows to catch regressions early.