🤔 [Question]: CORS+AWS preflight issue since v2.52.2

[acidjazz]

Bug Description

CORS has not worked for us since v2.52.2 of gofiber on AWS - I have created a reproduction repo here:

https://github.com/fumeapp/fiber-cors

I will be updating this issue as I dig into the differences/issues

How to Reproduce

https://github.com/fumeapp/fiber-cors

Expected Behavior

should return cors

Fiber Version

v2.52.2

• I agree to follow Fiber's Code of Conduct.
• I have checked for existing issues that describe my problem prior to opening this one.
• I understand that improperly formatted bug reports may be closed without explanation.

[ReneWerner87]

After v2.52.2 means its related to v2.52.3

Cors related changes in this release
#2915
#2921

[ReneWerner87]

Should be related to the change coming from #2920

[sixcolors]

Fiber used to incorrectly respond to OPTIONS requests as if they were CORS preflights even when they were missing the required headers. That bug was fixed in v2.52.2. Now, Fiber properly distinguishes between a valid CORS preflight and a regular OPTIONS request — which is what's exposing the misconfiguration in the user's infrastructure.

---

🔍 The Problem:

• The client (e.g. browser) sends a CORS preflight request.

• But the Access-Control-Request-Method header is missing or stripped.

• This makes the request not a valid preflight, as defined in the spec:

  A request is a CORS-preflight request if its method is OPTIONS, it includes an Origin header, and it includes an Access-Control-Request-Method header.

  Ref: Fetch Spec § CORS-preflight request

---

✅ Expected Behavior (Post-v2.52.2):

• Fiber, seeing an OPTIONS request without Access-Control-Request-Method, treats it as a normal OPTIONS request, not a CORS preflight.
• Since no explicit OPTIONS route handler is registered for that path, Fiber returns a 405 — this is correct and spec-compliant.

---

🛠️ Root Cause:

• Some component in the user’s infrastructure (could be CloudFront, API Gateway, ALB, WAF, a load balancer, or even middleware) is stripping or failing to forward the Access-Control-Request-Method header.

• This might happen due to:

  • Misconfigured cache behavior (CloudFront or other CDN)
  • Missing headers in the origin request or cache policy
  • Proxy or rewrite rules that drop headers

Note: I tested a basic Fiber app behind CloudFront on EC2 with CORS enabled and preflight works fine — so the issue isn’t CloudFront generally, but rather some config or intermediary.

Useful AWS resources:

• https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html
• https://repost.aws/knowledge-center/no-access-control-allow-origin-error
• https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-cors.html

---

✅ Fix:

Ensure that every layer between the browser and your Fiber app:

1. Forwards all headers, especially:

   • Origin
   • Access-Control-Request-Method
   • Access-Control-Request-Headers

2. Does not cache OPTIONS requests without differentiating on those headers.

3. Does not remove or overwrite these headers due to a misconfigured behavior, rewrite rule, or middleware.

---

✅ Suggested Debugging:

• Log the raw OPTIONS request received by Fiber (including headers).
• Use curl or fetch to simulate a full preflight request and compare what Fiber receives vs what you send.
• Use tools like AWS CloudWatch logs, curl with -v, or browser dev tools to trace what’s being sent and received.

You can also add this middleware before app.Use(cors.New(...)) to log headers Fiber sees and replies with:

app.Use(func(c *fiber.Ctx) error {
    fmt.Printf("→ %s %s | Origin: %s\n", c.Method(), c.Path(), c.Get("Origin"))
    fmt.Printf("→ Request Headers: %v\n", c.GetReqHeaders())
    err := c.Next()
    fmt.Printf("← Response Headers: %v\n", c.GetRespHeaders())
    fmt.Printf("← %s %s | Status: %d\n", c.Method(), c.Path(), c.Response().StatusCode())
    return err
})

---

Let me know what sits in front of the Fiber app (CloudFront, ALB, API Gateway, etc.), and I can help narrow it down.

[sixcolors]

How we know Request headers are being stripped, from discord chat with user:

curl -H "Origin: https://fiber-cors-nuxt.acidjazz.workers.dev" \-H "Access-Control-Request-Method: GET" \
-X OPTIONS -I  https://d245hvitoez60u.cloudfront.net

[sixcolors]

Since v3 is also spec compliant for CORS this applies to it too.

[acidjazz]

We were able to move passed v2.52.2 by enabling these headers in a custom Cache policy

[acidjazz]

i think this should be closed with a note in the CORS middleware documentation in general about these headers - but also pointing out that AWS CloudFront does this by default, and that a custom cache policy is recommended (pre-configured ones are not modifiable)