Cors Wildcard in Buffalo with Basic Auth

The combination of a CORS wildcard and HTTP Basic Authentication in Buffalo can unintentionally expose authenticated endpoints to any origin. In Buffalo, CORS settings are typically configured in actions/app.go using the CORS middleware. When the middleware is set with cors.New(cors.Options{AllowedOrigins: []string{"*"}}), any domain can send a request and read the response. If the handler relies on Basic Auth in headers (e.g., Authorization: Basic base64(username:password)), the browser may automatically include credentials in cross-origin requests when WithCredentials is enabled on the client or when the middleware is configured to allow credentials. A wildcard origin with allowed credentials violates the CORS spec’s safe default and can allow a malicious site to make authenticated requests on behalf of a user, provided the browser sends the Authorization header and the server responds.

Buffalo’s runtime does not inherently validate the origin before processing Basic Auth. If the CORS middleware permits credentials with a wildcard, preflight requests (OPTIONS) may succeed and the actual authenticated GET or POST can be read by JavaScript on the attacker’s page. This exposes session-equivalent credentials (the Base64-encoded username:password pair) to cross-origin leakage when the response is readable. An attacker can craft a page that issues an authenticated fetch to your Buffalo endpoint; if the server responds with JSON containing sensitive data and the CORS headers incorrectly allow any origin, the data can be exfiltrated via the attacker’s script.

Consider a handler designed to return account details. With a wildcard CORS policy and Basic Auth, an attacker can perform CSRF-like cross-origin reads if the browser includes the Authorization header and the endpoint does not validate the origin. While Basic Auth over HTTPS protects the credentials in transit, the server-side response can be accessed by malicious JavaScript when CORS allows it. This is distinct from authentication bypass; the credentials are present and valid, but the server erroneously shares the data with any requesting origin. The vulnerability is a result of the permissive CORS configuration combined with the assumption that Basic Auth alone prevents cross-origin access, which is not sufficient in a browser context with wildcard origins and exposed response headers.

To detect this pattern, scanners evaluate whether CORS headers include Access-Control-Allow-Origin: * while also allowing credentials, and whether authentication mechanisms like Basic Auth are applied to endpoints that must be origin-restricted. The presence of both increases risk because it can permit unauthorized cross-origin data retrieval. Remediation involves tightening CORS origins, avoiding wildcard origins when credentials are required, and ensuring that sensitive endpoints validate the request origin explicitly rather than relying solely on transport-layer authentication.

Secure remediation in Buffalo involves replacing broad CORS wildcard usage with explicit origins and ensuring that authenticated handlers validate the request origin. When using Basic Auth, you should never allow credentials from any origin. Instead, define a strict allowlist and configure the CORS middleware accordingly.

Example: Secure CORS with Basic Auth in Buffalo

Below is a concrete, syntactically correct configuration in actions/app.go. It sets allowed origins to a specific list, disables wildcard, and ensures credentials are only allowed for trusted origins. The Basic Auth check is performed in a before action to reject unauthorized requests early.

package actions

import (
	"net/http"
	"strings"

	"github.com/gobuffalo/buffalo"
	"github.com/gobuffalo/buffalo/middleware"
	"github.com/gobuffalo/buffalo/middleware/cors"
)

func App() *buffalo.App {
	app := buffalo.New(buffalo.Options{
		Env:         ENV,
		SessionStore: &middleware.SessionCookieStore{},
	})

	// Strict CORS policy: specific origins, allow credentials, no wildcard
	app.Use(cors.New(cors.Options{
		AllowedOrigins:   []string{"https://trusted.example.com", "https://app.example.com"},
		AllowedMethods:   []string{"GET", "POST", "OPTIONS"},
		AllowedHeaders:   []string{"Authorization", "Content-Type"},
		ExposedHeaders:   []string{"Content-Type"},
		AllowCredentials: true,
		MaxAge:           3600,
	}))

	// Basic Auth before action for protected endpoints
	app.Before(beforeAuth, buffalo.All)

	// Define your routes as usual
	app.GET("/api/account", AccountHandler)
	app.POST("/api/update", UpdateHandler)

	return app
}

// beforeAuth checks HTTP Basic Auth and rejects invalid credentials
func beforeAuth(r buffalo.Request) error {
	// Skip auth for public endpoints if needed
	publicPaths := []string{"/health", "/docs"}
	for _, p := range publicPaths {
		if r.Request().URL.Path == p {
			return nil
		}
	}

	hdr := r.Request().Header.Get("Authorization")
	if hdr == "" {
		return r.Render(401, r.JSON(&Error{Message: "Authorization header required"}))
	}

	const prefix = "Basic "
	if !strings.HasPrefix(hdr, prefix) {
		return r.Render(401, r.JSON(&Error{Message: "Invalid authorization type"}))
	}

	payload, err := base64.StdEncoding.DecodeString(hdr[len(prefix):])
	if err != nil {
		return r.Render(401, r.JSON(&Error{Message: "Invalid authorization header"}))
	}

	pair := strings.SplitN(string(payload), ":", 2)
	if len(pair) != 2 || pair[0] != "admin" || pair[1] != "secret" {
		return r.Render(401, r.JSON(&Error{Message: "Invalid username or password"}))
	}

	return nil
}

If you prefer to keep credentials on the client and rely on server-side validation only, ensure CORS does not allow credentials with a wildcard. The following incorrect configuration should be avoided:

// UNSAFE: wildcard with credentials
app.Use(cors.New(cors.Options{
	AllowedOrigins:   []string{"*"},
	AllowCredentials: true, // Do not combine with "*"
}))

Additionally, always serve Basic Auth over HTTPS to protect the Base64-encoded credentials in transit. While Base64 is not encryption, HTTPS prevents on-path eavesdropping. For higher security, consider migrating to token-based authentication (e.g., JWT) where possible, but if you must use Basic Auth, ensure strict origin policies and validate the Origin header on the server when additional context is available.

These fixes ensure that authenticated responses are not exposed to arbitrary origins, mitigating cross-origin data disclosure while preserving the intended access patterns for your Buffalo application.