Summary
Fiber cache middleware's default key generator uses only c.Path() and does not include the query string.
As a result, requests like /?id=1 and /?id=2 can map to the same cache key and share the same cached response.
This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.
Details
Default configuration in cache middleware:
KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }
References:
The existing test demonstrates that when handler output depends on query parameter id, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.
PoC
Minimal PoC:
package main
import (
"log"
"github.com/gofiber/fiber/v3"
"github.com/gofiber/fiber/v3/middleware/cache"
)
func main() {
app := fiber.New()
app.Use(cache.New()) // default config
app.Get("/", func(c fiber.Ctx) error {
return c.SendString(c.Query("id", "1"))
})
log.Fatal(app.Listen(":3000"))
}
Reproduction:
GET /?id=1
- Cache miss
- Response body:
1
GET /?id=2
- Cache hit
- Response body:
1 (expected 2)
Local verification command used:
go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1
Observed result: test passes, confirming this is current behavior.
Impact
- Responses that should vary by query parameters can be mixed between requests.
- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.
- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.
Suggested remediation
- Change default cache key generation to include path + normalized query string (or canonicalized original URL).
- Keep ability for custom key generators.
- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.
References
Summary
Fiber cache middleware's default key generator uses only
c.Path()and does not include the query string.As a result, requests like
/?id=1and/?id=2can map to the same cache key and share the same cached response.This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.
Details
Default configuration in cache middleware:
KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }References:
The existing test demonstrates that when handler output depends on query parameter
id, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.PoC
Minimal PoC:
Reproduction:
GET /?id=11GET /?id=21(expected2)Local verification command used:
go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1Observed result: test passes, confirming this is current behavior.
Impact
Suggested remediation
References