HIGH cors wildcardfiberbasic auth

Cors Wildcard in Fiber with Basic Auth

Cors Wildcard in Fiber with Basic Auth — how this specific combination creates or exposes the vulnerability

Cross-origin resource sharing (CORS) misconfigurations in Fiber can expose Basic Auth–protected endpoints to unauthorized origins when a wildcard Access-Control-Allow-Origin is combined with credentialed requests. In browsers, requests with credentials (cookies, HTTP authentication) are considered non‑simple. For non‑simple requests, browsers require a preflight (OPTIONS) that validates Access-Control-Allow-Origin against an explicit origin and checks that Access-Control-Allow-Credentials is not set to true when the origin is a wildcard.

Basic Auth-Specific Remediation in Fiber — concrete code fixes

To secure a Fiber API that uses Basic Auth, configure CORS with explicit origins and ensure credentials are only allowed where necessary. Below are concrete, working examples in Go using the Fiber framework.

Example 1: Strict CORS with Basic Auth

This example sets specific origins, does not allow credentials globally, and adds selective credential support for a trusted origin.

package main

import (
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/cors"
)

func main() {
	app := fiber.New()

	// Define allowed origins explicitly
	allowedOrigins := []string{
		"https://app.yourcompany.com",
		"https://staging.yourcompany.com",
	}

	app.Use(cors.New(cors.Config{
		AllowOrigins:     allowedOrigins,
		AllowCredentials: false, // do not allow credentials by default
		AllowHeaders:     "Authorization, Content-Type",
		AllowMethods:     "GET, POST, PUT, DELETE, OPTIONS",
		ExposeHeaders:    "X-Total-Count",
		MaxAge:           3600,
	}));

	// Protected endpoint that uses Basic Auth
	app.Get("/secure/data", func(c *fiber.Ctx) error {
		user, pass, ok := c.BasicAuth()
		if !ok {
			return c.SendStatus(fiber.StatusUnauthorized)
		}
		if user != "admin" || pass != "S3cureP@ss!" {
			return c.SendStatus(fiber.StatusForbidden)
		}
		return c.JSON(fiber.Map{"data": "protected resource"})
	})

	app.Listen(":3000")
}

Example 2: Per-route credentialed CORS for a trusted origin

If a specific origin must send credentials, apply CORS per route and set AllowCredentials only for that route, keeping the global default false.

app.Get("/trusted", func(c *fiber.Ctx) error {
	// Apply per-route CORS with credentials for a single trusted origin
	opts := cors.Config{
		AllowOrigins:     []string{"https://partner.yourcompany.com"},
		AllowCredentials: true,
		AllowHeaders:     "Authorization, Content-Type",
		AllowMethods:     "GET, OPTIONS",
		MaxAge:           3600,
	}
	c.Locals("cors", opts)

	user, pass, ok := c.BasicAuth()
	if !ok {
		return c.SendStatus(fiber.StatusUnauthorized)
	}
	if user != "partner" || pass != "P@ssw0rd!" {
		return c.SendStatus(fiber.StatusForbidden)
	}
	return c.JSON(fiber.Map{"data": "trusted resource"})
})

Why this mitigates the risk

  • Access-Control-Allow-Origin is set to explicit origins rather than *, preventing arbitrary origins from reading responses even when credentials are present.
  • Access-Control-Allow-Credentials is kept false globally, so browsers will not include cookies or authentication headers for cross-origin requests to wildcard or mismatched origins.
  • When credentials are required, CORS is applied per route with a tightly scoped origin and short MaxAge for preflight caching, reducing exposure.
  • Basic Auth over HTTPS is enforced; the examples assume TLS termination upstream, ensuring credentials are not transmitted in cleartext.

Related CWEs: dataExposure

CWE IDNameSeverity
CWE-200Exposure of Sensitive Information HIGH
CWE-209Error Information Disclosure MEDIUM
CWE-213Exposure of Sensitive Information Due to Incompatible Policies HIGH
CWE-215Insertion of Sensitive Information Into Debugging Code MEDIUM
CWE-312Cleartext Storage of Sensitive Information HIGH
CWE-359Exposure of Private Personal Information (PII) HIGH
CWE-522Insufficiently Protected Credentials CRITICAL
CWE-532Insertion of Sensitive Information into Log File MEDIUM
CWE-538Insertion of Sensitive Information into Externally-Accessible File HIGH
CWE-540Inclusion of Sensitive Information in Source Code HIGH

Frequently Asked Questions

Can a wildcard CORS configuration be safe if credentials are not used?
Yes, if your endpoints never require credentials (cookies, HTTP authentication, or TLS client certificates), a wildcard Access-Control-Allow-Origin: * can be acceptable. However, once Basic Auth or session cookies are in play, a wildcard origin with credentials is unsafe because it allows any site to make authenticated requests on behalf of users.
Does middleBrick detect CORS misconfigurations like a wildcard with Basic Auth?
Yes. middleBrick runs 12 security checks in parallel, including CORS and Authentication, and maps findings to frameworks such as OWASP API Top 10. With the Pro plan you can enable continuous monitoring so that regressions—such as a CORS configuration inadvertently allowing credentials with a wildcard—are flagged automatically in your CI/CD pipeline.