Cors Wildcard in Echo Go with Api Keys

In Echo Go, configuring CORS with a wildcard origin while also using API keys can unintentionally expose authenticated endpoints to any web origin. A typical insecure pattern looks like this:

e := echo.New()
e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
    AllowOrigins: []string{"*"},
    AllowHeaders: []string{echo.HeaderAuthorization},
}))
e.GET("/admin", func(c echo.Context) error {
    key := c.Request().Header.Get("X-API-Key")
    if key != "super-secret" {
        return echo.ErrUnauthorized
    }
    return c.String(http.StatusOK, "admin data")
})

Here, AllowOrigins: []string{"*"} allows any web page to make requests to the endpoint. The browser will include credentials such as cookies and HTTP authentication headers when the CORS request is made, but because the route also relies on an API key in a header, a malicious site can send requests that include the API key if the key is stored client-side (for example, in JavaScript or a mobile app’s embedded webview). The browser’s CORS policy will permit the cross-origin call to proceed, and the backend may mistakenly treat the presence of the API key as sufficient authorization, leading to unauthorized data access or actions.

This combination violates the principle that broad origins and strong authentication mechanisms should not be casually layered without carefully considering how browsers enforce CORS. The API key is a bearer credential; if it is embedded or otherwise accessible to JavaScript on any origin, any site can perform actions on behalf of the key holder. Moreover, preflight requests will succeed due to the wildcard, and non-simple requests that include the Authorization header (or custom headers like X-API-Key) will be allowed, further widening the attack surface. This setup can facilitate cross-origin abuse patterns such as CSRF-like behavior where an authenticated request is initiated from a malicious site, potentially leading to data exposure or unintended state changes.

Additionally, if the API key is passed as a query parameter rather than a header, logging or referrer leaks can expose it to third-party sites. Even with strict header-based keys, the wildcard origin removes any origin-based restriction, making it difficult to enforce a strict same-origin policy. The vulnerability is not in Echo Go itself but in the configuration choices that fail to scope origins to known, trusted domains when strong credentials are in play.

Remediation centers on narrowing CORS origins and ensuring API keys are handled in a way that does not rely on broad trust boundaries. First, replace the wildcard with an explicit allowlist of origins that your frontend(s) actually use:

e := echo.New()
e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
    AllowOrigins: []string{"https://app.example.com", "https://dashboard.example.com"},
    AllowHeaders: []string{echo.HeaderAuthorization, "X-API-Key"},
    AllowCredentials: true,
}))
e.GET("/admin", func(c echo.Context) error {
    key := c.Request().Header.Get("X-API-Key")
    if key != "super-secret" {
        return echo.ErrUnauthorized
    }
    return c.String(http.StatusOK, "admin data")
})

By specifying concrete origins and enabling AllowCredentials only when necessary, you prevent cross-origin requests from untrusted sources while still allowing your legitimate frontend to authenticate with the API key. Ensure that the frontend sends the key in a secure, HTTP-only context where possible, and avoid embedding keys in JavaScript that could be extracted by malicious sites.

For server-to-server scenarios, consider using a more robust authentication scheme alongside API keys, such as mutual TLS or signed requests, to reduce reliance on static headers that can be leaked. If you use the middleBrick CLI to validate your configuration, you can run middlebrick scan <url> to verify that CORS settings are not overly permissive. Teams on the Pro plan can enable continuous monitoring to detect regressions in CORS or key handling automatically, and the GitHub Action can fail builds if scans detect a wildcard origin on authenticated endpoints.

Example of a secure key validation pattern that avoids common pitfalls:

const expectedKey = os.Getenv("API_KEY")
e.GET("/secure", func(c echo.Context) error {
    provided := c.Request().Header.Get("X-API-Key")
    if subtle.ConstantTimeCompare([]byte(provided), []byte(expectedKey)) != 1 {
        return echo.NewHTTPError(http.StatusUnauthorized, "invalid key")
    }
    return c.NoContent(http.StatusOK)
})

This uses constant-time comparison to mitigate timing attacks on the key check. Combine this with a restricted CORS policy to ensure that only authorized origins can invoke the endpoint, reducing the risk of cross-origin key misuse.