Cors Wildcard in Chi with Jwt Tokens

In a Chi application, using a CORS policy that allows any origin (origins = ["*"]) while also validating JWT tokens can unintentionally expose authenticated endpoints to cross-origin requests. When the CORS configuration permits all origins, any website can make authenticated requests on behalf of a user if the user’s browser automatically includes credentials such as cookies or authorization headers. Even though JWT tokens are often stored in JavaScript-accessible storage (e.g., localStorage), many Chi routes rely on cookie-based session affinity or custom headers to pass the token. If the server responds with Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: * simultaneously, browsers will reject the response due to CORS spec safety rules, but misconfigured setups that allow specific trusted origins alongside wildcard expectations can lead to authorization bypass opportunities.

The vulnerability arises when developers mistakenly believe that JWT validation alone is sufficient to protect an endpoint. CORS is a browser-enforced mechanism; it does not prevent server-to-server calls or malicious clients. If the Chi middleware permits wildcard origins while also allowing credentials, an attacker can craft a malicious site that triggers authenticated requests via JavaScript (e.g., using fetch). Even if the browser blocks the response, the request may still reach the server, potentially exposing routing or error information. In Chi, this often manifests as permissive CORS configurations during development that are inadvertently promoted to production without tightening origins when JWT tokens are used for authorization.

Chi routes that rely on JWT tokens typically extract the token from the Authorization header. If the CORS policy is too permissive, preflight requests (OPTIONS) may succeed with wildcard origins, leading developers to assume safety. However, the combination of wildcard origins and JWT-based authentication does not inherently protect against Cross-Site Request Forgery (CSRF) when credentials are involved. Proper mitigation involves explicitly defining allowed origins, ensuring that Access-Control-Allow-Origin is not set to * when credentials are required, and aligning CORS settings with the authentication mechanism. MiddleBrick scans can detect such risky configurations during unauthenticated scans, identifying mismatches between CORS rules and token usage.

To secure a Chi application using JWT tokens, configure CORS with explicit origins and avoid wildcard allowances when credentials are involved. Below is a minimal, secure Chi configuration in F# that demonstrates proper CORS and JWT validation. This example uses the Chessie.Chardonnay-style middleware common in Chi and shows how to restrict origins while validating JWTs in the request pipeline.

open System.IdentityModel.Tokens.Jwt
open System.Security.Claims
open Microsoft.AspNetCore.Http
open FSharp.Control.Tasks
open Giraffe
open Microsoft.AspNetCore.Cors

// Define allowed origins explicitly — never use "*" when using credentials
let allowedOrigins = [| "https://app.example.com"; "https://admin.example.com" |]

// JWT validation handler
let validateJwt (next: HttpFunc -> IHttpContext -> Task<HttpFuncResult>) (ctx: HttpContext) =
    task {
        let authHeader = ctx.Request.Headers.["Authorization"].ToString()
        if authHeader.StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase) then
            let token = authHeader.Substring(7)
            // Replace with your actual validation logic, e.g., using JwtSecurityTokenHandler
            // For illustration, we assume a valid token contains a specific claim
            if token.Contains("valid") then
                return! next ctx
            else
                return! Unauthorized "Invalid token" ctx
        else
            return! Unauthorized "Missing token" ctx
    }

// CORS policy that works with JWT tokens
let corsPolicy = CorsPolicy()
corsPolicy.Origins.Add("https://app.example.com")
corsPolicy.Origins.Add("https://admin.example.com")
corsPolicy.AllowAnyMethod() |> ignore
corsPolicy.AllowAnyHeader() |> ignore
corsPolicy.AllowCredentials() |> ignore

// Apply CORS and JWT validation in the router
let webApp = 
    choose [
        GET >=> 
            CorsMiddleware.cors corsPolicy (validateJwt (fun ctx next -> 
                task {
                    return! Successful.OK "Authenticated and CORS-enabled" ctx
                }))
        _ -> notFound "Not found"
    ]

// In Program.fs, add CORS services and middleware
// builder.Services.AddCors(fun options -> options.AddPolicy("SecurePolicy", fun policy -> 
//     policy.WithOrigins(["https://app.example.com"]); 
//     policy.AllowAnyHeader(); 
//     policy.AllowCredentials())
// ) |> ignore
// app.UseCors("SecurePolicy")

In this setup, CORS origins are explicitly listed, preventing wildcard exposure. The JWT validation occurs after CORS preflight checks, ensuring that only requests from allowed origins are processed. For production, consider storing the allowed origins in configuration and using a robust JWT library such as Jose or System.IdentityModel.Tokens.Jwt for signature validation and claim verification. MiddleBrick’s OpenAPI/Swagger analysis can verify that your spec does not advertise wildcard origins when security schemes involving JWT tokens are present.

Additionally, avoid storing JWTs in localStorage in SPAs when using cookie-based CORS credentials; prefer short-lived tokens and secure, HTTP-only cookies where possible. If your Chi service is exposed via an API gateway, ensure that CORS headers are enforced at the gateway level as well. The Pro plan of middleBrick supports continuous monitoring to detect regressions in CORS and authentication configurations over time, and the GitHub Action can fail builds if insecure CORS rules are detected during CI/CD pipeline runs.