Currently in the process of trying to create some sample concerning CORS configuration of S3, and making a small sample allowing people to create their own CORS rules for their bucket but still allowing the app.localstack.cloud / resource browser to access it, I've encountered an issue with the ListBuckets operation.

S3 is a "self-managed" CORS service, as it can manage the CORS setting of its buckets. However, the ListBuckets operation is not configurable, and should be using the default CORS setting of LocalStack. I've added a check in our general CORS handler to not skip setting CORS headers if the operation is ListBuckets.

While creating the test, I've also found that if you try to access http://localhost:4566, it should return ListBuckets, but our service name parser does not recognise the request as it's not signed.
Funnily, in AWS, if you do the same and try to access s3.amazonaws.com which is the default URL for ListBuckets in us-east-1 without signing the request, you get redirected to https://aws.amazon.com/s3/.

If you use s3.localhost.localstack.cloud without signing the request, you'll get the response for ListBuckets because of the host matching.
Should we match on the path being / as a sign of an S3 request?