Excessive Data Exposure in Echo Go with Api Keys

Excessive Data Exposure occurs when an API returns more information than necessary for a given operation. In Echo Go, this commonly arises around API key handling when responses include keys or key-like values that should never be returned to the caller. For example, an endpoint that creates or updates a key might echo the full key value back in the JSON response, or return related metadata that, when combined with other endpoints, reveals the key material.

In Echo Go, a typical pattern is to bind a request body to a struct that includes a field for the API key, then persist it and return a response struct that also contains the key field. If the key field is populated and the struct is serialized back without filtering, the key is effectively exposed in the HTTP response. This becomes a security issue when the response is captured in logs, browser history, or by an intermediary, and the key is treated as a bearer credential.

Echo Go routes are often organized around resource-oriented URLs such as /api/v1/keys/{id}. If a GET or PUT handler returns the full key object including the secret value, any consumer of that endpoint can see the key. This violates the principle of least privilege for data exposure and can lead to scenarios where compromised client-side code or an accidental log results in key leakage. Because API keys function as bearer tokens, exposure through response bodies increases the risk of unauthorized access similar to leaked credentials.

Another common pattern involves reflection-based serialization in Echo Go, where the response struct mirrors the request struct. If the key is stored server-side but the handler inadvertently includes the key field in the outgoing JSON, the key can propagate unintentionally. Even if the key is stored securely, returning it in responses creates a chain of risk: browser dev tools, network traces, and server logs may retain the value, and any client-side error handling might surface it to unintended parties.

The interaction with other security checks in middleBrick is relevant here. For instance, middleBrick’s Data Exposure check can identify endpoints that return sensitive fields such as api_key or secret in responses. When combined with Authentication and BOLA/IDOR findings, excessive data exposure can be contextualized: an exposed key in a response may enable horizontal privilege escalation if the key is user-specific and can be reused across accounts.

Real-world examples include responses that contain fields like "api_key": "sk_live_abc123" or "token": "". These values should be omitted from serialization, for instance by using json:"-" tags or by using separate response structs that exclude sensitive fields. middleBrick’s OpenAPI/Swagger analysis can highlight schema definitions that declare such sensitive properties, and runtime checks can confirm whether those properties are surfaced in actual responses.

Remediation focuses on ensuring API key values are never returned in HTTP responses and are handled securely during request processing. Below are concrete patterns and code examples for Echo Go.

1. Use distinct request and response structs

Define a request struct that includes the key for input, and a response struct that excludes it. This prevents accidental echoing of the key.

// Request struct (used to bind incoming JSON)
type CreateKeyRequest struct {
    Name string `json:"name"`
    Scope string `json:"scope"`
}

// Response struct (used to serialize outgoing JSON)
type KeyResponse struct {
    ID   string `json:"id"`
    Name string `json:"name"`
    Scope string `json:"scope"`
    // Deliberately omitting the API key field
}

func CreateKey(c echo.Context) error {
    var req CreateKeyRequest
    if err := c.Bind(&req); err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "invalid payload")
    }
    // Assume generateKey() returns the key stored server-side
    key, err := generateKey(req.Name, req.Scope)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError, "failed to create key")
    }
    // Respond without exposing the key
    resp := KeyResponse{
        ID: key.ID,
        Name: key.Name,
        Scope: key.Scope,
    }
    return c.JSON(http.StatusCreated, resp)
}

2. Use json:"-" for sensitive fields on shared structs

If you must use a single struct, tag the key field with json:"-" to exclude it from JSON serialization.

type KeyModel struct {
    ID string `json:"id"`
    Name string `json:"name"`
    Secret string `json:"-"` // will not appear in JSON output
}

func GetKey(c echo.Context) error {
    key, err := fetchKeyFromStore(c.Param("id"))
    if err != nil {
        return echo.NewHTTPError(http.StatusNotFound, "key not found")
    }
    // Secret is omitted from JSON due to json:"-"
    return c.JSON(http.StatusOK, key)
}

3. Avoid binding entire payloads to models that include keys

Do not use c.Bind on a struct that contains a key field for responses. Instead, bind to a smaller input-specific struct and map to a response struct as shown above.

4. Secure storage and handling of keys

Store keys server-side with appropriate encryption at rest. When you must handle key material in memory, avoid logging and ensure buffers are cleared when no longer needed. Do not include keys in URLs or query parameters.

5. Validate and scope keys

Ensure that key-referencing endpoints enforce proper ownership checks. Even when keys are not exposed, ensure that BOLA/IDOR protections are in place so one user cannot access another’s keys.

middleBrick can validate these remediations by checking that response schemas do not include sensitive fields such as api_key, secret, or token, and by confirming that runtime responses for key-related endpoints do not contain those values.