Cross Site Request Forgery in Echo Go with Api Keys

Cross Site Request Forgery (CSRF) in an Echo Go API that relies solely on API keys can occur when API keys are treated as equivalent to session cookies and are automatically included by browsers in requests initiated from malicious third-party sites. In Echo Go, if you read the API key from an Authorization header such as Authorization: ApiKey <key> and your application does not enforce additional same-site or origin checks, a browser-based attacker can craft an img or fetch request that the browser sends automatically, including the key if it is stored in a predictable location like localStorage and exposed to JavaScript.

Consider an endpoint that performs a state-changing operation, such as transferring funds or changing an email address, and only checks for an API key in the header. If the API key is embedded in frontend JavaScript or leaked via logs or referrer headers, a malicious site can induce the victim’s browser to make authenticated requests without consent. The CSRF risk is compounded when API keys are long-lived and lack scope restrictions, and when Echo Go routes do not validate the Origin or Referer headers as an additional defense. Even though API keys are not cookies, if the client stores them in a way that the browser automatically attaches them (for example, via custom headers injected by a global axios instance), the request can be forged.

For example, an attacker might host a page that triggers a funds transfer on behalf of an authenticated user. If the user has previously authenticated to your Echo Go service and the API key remains in browser storage, a script like the following running on the attacker’s site could execute an unintended action:

fetch('https://api.example.com/v1/account/transfer', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    // If the client adds ApiKey automatically via an interceptor, the browser may include it
    'Authorization': 'ApiKey ' + localStorage.getItem('apiKey')
  },
  body: JSON.stringify({ to: 'attacker_account', amount: 5000 })
});

Although the browser does not automatically attach custom headers like Authorization in cross-origin requests unless explicitly allowed via CORS, if the Echo Go API exposes permissive CORS rules (e.g., * or specific origins that include the attacker’s site) and the API key is managed via JavaScript, the request may be sent. The key takeaway is that treating API keys as bearer tokens without anti-CSRF mitigations such as same-site attributes, strict origin validation, or double-submit cookie patterns can expose state-changing endpoints to CSRF when used in browser contexts.

To mitigate CSRF in Echo Go when using API keys, avoid relying on browser automatic credential inclusion and enforce explicit checks. Prefer storing API keys in secure, httpOnly cookies with SameSite=Strict or Lax, and require a custom header (e.g., X-API-Key) for requests so that simple cross-origin requests cannot include the key. If you must keep keys in JavaScript-accessible storage, implement strict CORS policies and validate Origin/Referer headers on the server.

Below are concrete code examples for an Echo Go handler that requires an API key via header and includes CSRF-conscious practices.

Example API key validation middleware in Echo Go:

func APIKeyMiddleware(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        const expectedKey = "s3cr3t-k3y"
        provided := c.Request().Header.Get("X-API-Key")
        if provided != expectedKey {
            return echo.NewHTTPError(http.StatusUnauthorized, "invalid api key")
        }
        return next(c)
    }
}

// Apply the middleware to state-changing routes
app.POST("/v1/account/transfer", APIKeyMiddleware(transferHandler))

func transferHandler(c echo.Context) error {
    var req struct {
        To     string `json:"to"`
        Amount int    `json:"amount"`
    }
    if err := c.Bind(&req); err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "invalid request")
    }
    // Perform transfer logic here
    return c.JSON(http.StatusOK, map[string]string{"status": "ok"})
}

In this example, the API key is passed via a custom header X-API-Key rather than being automatically managed by the browser. The middleware ensures that each request includes the correct key. To further reduce CSRF risk, ensure CORS is locked down so that only trusted origins can call the endpoints:

func configureCORS(e *echo.Echo) {
    e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
        AllowOrigins: []string{"https://trusted.example.com"},
        AllowMethods: []string{echo.GET, echo.POST},
        AllowHeaders: []string{"X-API-Key", "Content-Type"},
        ExposeHeaders: []string{"Content-Length"},
        AllowCredentials: false,
    }))
}

For higher assurance, consider synchronizing CSRF tokens for browser-based flows even when using API keys, or adopt double-submit cookie patterns where a token in a cookie is compared with a header value. This ensures that requests originate from your own frontend rather than a malicious site, complementing the API key checks.