Cors Wildcard in Fiber with Jwt Tokens

In the Fiber web framework for Go, configuring CORS with a wildcard origin (*) while also using JWT tokens for authorization creates a security misconfiguration that can undermine token-based protection. When AllowOrigins: []string{"*"} is set, the server responds to preflight and simple requests with an Access-Control-Allow-Origin: * header, indicating that any origin can access the response.

To secure endpoints that validate JWT tokens, specify exact origins instead of a wildcard and ensure credentials are not inadvertently allowed across origins. Below are two concrete, working Fiber examples that demonstrate the vulnerable pattern and the remediated pattern.

Vulnerable setup: wildcard origin with JWT middleware

c := fiber.New()
c.Use(cors.New(cors.Config{
    AllowOrigins: "*",
    AllowMethods: "GET,POST,PUT,DELETE",
}))
c.Get("/profile", func(c *fiber.Ctx) error {
    token := c.Get("Authorization")
    if token == "" {
        return c.Status(fiber.StatusUnauthorized).SendString("missing token")
    }
    // naive/jwt validation omitted for brevity
    return c.SendString("profile")
})
c.Listen(":3000")

In this setup, an attacker can craft a page on any domain to call the protected endpoint. The browser sends credentials (cookies, authorization headers) with the request because Access-Control-Allow-Origin: * allows any origin to read the response. Even though the server requires a JWT, the overly permissive CORS policy can expose authenticated responses to unauthorized origins and enable cross-origin abuse when credentials are included.

Remediated setup: explicit origins and secure CORS for JWT endpoints

c := fiber.New()
c.Use(cors.New(cors.Config{
    AllowOrigins:     []string{"https://app.example.com", "https://admin.example.com"},
    AllowCredentials: true,
    AllowMethods:     "GET,POST,PUT,DELETE",
    AllowHeaders:     "Authorization,Content-Type",
}))
c.Get("/profile", func(c *fiber.Ctx) error {
    auth := c.Get("Authorization")
    if auth == "" {
        return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "authorization header required"})
    }
    const jwtSecret = "your-secret-key"
    token := auth[len("Bearer "):]
    parsed, err := jwt.Parse(token, func(token *jwt.Token) (interface{}, error) {
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("unexpected signing method")
        }
        return []byte(jwtSecret), nil
    })
    if err != nil || !parsed.Valid {
        return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "invalid token"})
    }
    return c.JSON(fiber.Map{"user": "alice"})
})
c.Listen(":3000")

This configuration restricts CORS to known front-end origins, enables credentials only where needed, and explicitly allows the Authorization header. The JWT validation logic checks the Bearer token on each request, rejecting malformed or missing tokens. By pairing explicit origins with proper token validation, you reduce the risk that a compromised page on another domain can misuse authenticated API responses.

Operational guidance

• Avoid AllowOrigins: "*" when endpoints rely on JWT tokens and also expect credentials or sensitive response data.
• Use the Fiber CORS middleware to enumerate exact origins and limit allowed headers and methods to what the API actually requires.
• Always validate JWT signatures, claims, and expiration on the server; do not rely on CORS to enforce authorization.
• In CI/CD, consider adding a scan with the middleBrick CLI to detect overly permissive CORS rules alongside authentication checks.