Cors Wildcard in Buffalo with Bearer Tokens

In Buffalo, configuring CORS with a wildcard origin (*) while also using Bearer token authentication creates a critical exposure because the wildcard allows any origin to present a valid token on behalf of users. When an endpoint relies on Authorization headers (Bearer tokens) and responds with Access-Control-Allow-Origin: *, the browser includes credentials in cross-origin requests if withCredentials is enabled. This combination can unintentionally permit a malicious site to make authenticated requests and read the response if the server does not also validate the Origin header against an allowlist.

Buffalo’s default CORS settings may permit all origins, and if developers add Bearer token validation without narrowing CORS origins, the token is effectively exposed to any website. An attacker can craft a page that loads your API via JavaScript, attaches the stolen or leaked token, and reads the response. This violates the same-origin policy’s protection boundary and can lead to account takeover or data exfiltration.

Consider an API endpoint that returns sensitive user data and uses a middleware to verify Bearer tokens but sets CORS headers permissively:

// Buffalo middleware example (insecure wildcard with Bearer) in actions/app.go
func App() *buffalo.App {
    app := buffalo.New(buffalo.Options{})
    app.Use(CORS(&CORSConfig{
        AllowedOrigins: []string{"*"},
        AllowedMethods: []string{"GET", "POST", "OPTIONS"},
        AllowedHeaders: []string{"Authorization", "Content-Type"},
        ExposedHeaders: []string{"Content-Type"},
        MaxAge:         300,
        AllowCredentials: true,
    }))
    app.GET("/api/profile", ProfileHandler, authRequired)
    return app
}

In this configuration, AllowCredentials: true combined with AllowedOrigins: ["*"] is disallowed by browser security standards; browsers will reject the response. However, if the developer relaxes rules to allow credentials with a wildcard or uses a dynamic origin reflector without strict validation, a browser will send cookies and the Authorization header to the attacker’s page. The token in the Authorization header becomes usable cross-origin, enabling CSRF and unauthorized reads if other defenses (like anti-CSRF tokens) are absent.

For Bearer tokens, the threat is not cookie theft but token leakage via cross-origin JavaScript. If the frontend runs on https://evil.com and your API responds with Access-Control-Allow-Origin: * and includes the Authorization header in Access-Control-Expose-Headers, JavaScript can read the response and exfiltrate the token. Therefore, the specific combination of CORS wildcard and Bearer tokens creates a vulnerability where token confidentiality and integrity are at risk across origins.

Remediation requires replacing the wildcard with an explicit allowlist of trusted origins and ensuring that credentials and exposed headers are tightly controlled. For Bearer tokens, you typically do not need to expose headers to JavaScript, but if you do, list only necessary headers and avoid wildcard origins.

Here is a secure Buffalo CORS configuration that addresses the issue while supporting Bearer tokens:

// Secure Buffalo CORS configuration in actions/app.go
func App() *buffalo.App {
    app := buffalo.New(buffalo.Options{})
    app.Use(CORS(&CORSConfig{
        AllowedOrigins:   []string{"https://trusted.example.com", "https://app.example.com"},
        AllowedMethods:   []string{"GET", "POST", "OPTIONS"},
        AllowedHeaders:   []string{"Authorization", "Content-Type"},
        ExposedHeaders:   []string{}, // Avoid exposing Authorization to JS unless necessary
        MaxAge:           300,
        AllowCredentials: true,
    }))
    app.GET("/api/profile", ProfileHandler, authRequired)
    return app
}

If you must support multiple dynamic origins (e.g., multiple subdomains), compute the origin at runtime and reflect it only when it matches your allowlist:

// Dynamic origin validation in actions/app.go
var allowedOrigins = map[string]bool{
    "https://trusted.example.com": true,
    "https://app.example.com":     true,
}

func corsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
        origin := req.Header.Get("Origin")
        if allowedOrigins[origin] {
            rw.Header().Set("Access-Control-Allow-Origin", origin)
            rw.Header().Set("Access-Control-Allow-Credentials", "true")
            rw.Header().Set("Access-Control-Allow-Headers", "Authorization, Content-Type")
        }
        if req.Method == "OPTIONS" {
            rw.Header().Set("Access-Control-Allow-Methods", "GET, POST, OPTIONS")
            rw.WriteHeader(http.StatusOK)
            return
        }
        next.ServeHTTP(rw, req)
    })
}

func App() *buffalo.App {
    app := buffalo.New(buffalo.Options{})
    app.Use(corsMiddleware)
    app.GET("/api/profile", ProfileHandler, authRequired)
    return app
}

For Bearer tokens, ensure that token validation occurs before any CORS preflight or response. Do not rely on CORS alone for authorization; treat CORS as a browser-enforced boundary. In your authentication middleware, verify the token and reject malformed or missing tokens regardless of origin. This way, even if a request originates from an allowed domain, an invalid token will not grant access.

Finally, if your API is consumed by SPAs, use short-lived tokens and refresh token rotation. Store tokens securely (httpOnly cookies with SameSite=Lax or Strict when possible) and avoid embedding tokens in JavaScript-accessible storage to reduce exposure via XSS. The combination of strict origin allowlists, careful header exposure, and robust token validation significantly reduces the risk introduced by the Buffalo framework when using Bearer tokens.