🎉 I've just released v0.11.0 of jub0bs/cors, my CORS middleware library for #golang!

Bar any surprises, this will be the last minor release before v1.

https://github.com/jub0bs/cors

💣 This release brings a couple of simplifying but potentially breaking changes. None of them is very likely to affect you.
😇 The library's API is now simpler.
⚡Middleware execution during preflight is now faster and incurs fewer heap allocations.

💸 As always, sponsors are welcome!

https://pkg.go.dev/github.com/jub0bs/cors#pkg-index
https://github.com/jub0bs/cors/blob/v0.11.0/CHANGELOG.md
https://github.com/jub0bs/cors-benchmarks/blob/main/README.md#results
https://github.com/sponsors/jub0bs

💡 Did you know that you can craft URLs that bypass X/Twitter's URL shortener (t[.]co) and domain deny list?

For instance, try sharing https://x.com/login?redirect_after_login=https%3A%2F%2Fx.com%2Flogout%3Fredirect_after_logout%3Dhttps%253A%252F%252Fddosecrets%2525E3%252580%252582com in a tweet and clicking the link; you will ultimately be redirected to https://ddosecrets.com (which is banned by X) without ever traversing t[.]co!

It turns out that rs/cors (Go's most popular CORS middleware library) allocates a lot of memory in response to some malicious unauthenticated requests.

This behaviour could be abused to crash servers that run on limited memory, thereby causing a denial of service.

No such problem in my own library: https://github.com/jub0bs/cors 😇

Issue: https://github.com/rs/cors/issues/170
PR (not merged yet): https://github.com/rs/cors/pull/171

Unfortunately, I made a mistake while writing benchmarks for jub0bs/fcors. A mistake that ultimately fooled me into thinking that invocations of the CORS middleware it provides (almost) never incur heap allocations... but they do. Not a prohibitive amount, but still. 😞​

I was reusing the same http.ResponseRecorder across iterations of the benchmark loop, but making sure to clear its Header field during each iteration (because my middleware adds HTTP headers to the response). Of course, however, the new clear builtin leaves the capacity of the http.Header unchanged.

The call to ServeHTTP in the first iteration of the benchmark loop would grow the map as needed and, therefore, calls to ServeHTTP in subsequent iterations wouldn't incur any allocations.

I was deceived by the benchmark results, in which the allocations (only incurred during the first iteration) would get averaged out to zero. 😬​

I only realised my mistake after running the benchmark with -benchtime 1x.

Unfortunately, unless there is progress on https://github.com/golang/go/issues/56182, I don't think I can get rid of those heap allocations.

#golang