Skip to content

bug: S3 - CORS header parsing fails if Access-Control-Request-Headers lacks space after comma #12835

Closed
@maxvaz

Description

@maxvaz

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

In the current implementation, the CORS request headers are parsed using .split(", "), which assumes that all header names in the Access-Control-Request-Headers value are separated by a comma followed by a space.

However, according to the Fetch standard, HTTP header lists are comma-separated and optional whitespace may or may not be present. This means a value like "X-Custom-Header,Authorization" is valid and should be parsed as two separate headers.

Currently, the code:

for header in request_headers.lower().split(", ")

fails to correctly split the header string when there is no space after the comma, resulting in a single string like "x-custom-header,authorization", which breaks the CORS validation.

Expected Behavior

Expected behavior

CORS validation should handle Access-Control-Request-Headers values correctly whether or not there is a space after the comma, e.g.:

Access-Control-Request-Headers: X-Custom-Header,Authorization
and
Access-Control-Request-Headers: X-Custom-Header, Authorization

should both be treated identically.

Suggested fix
request_headers.lower().split(", ")
With:
[h.strip() for h in request_headers.lower().split(",")]

This ensures the headers are correctly parsed regardless of whitespace.

How are you starting LocalStack?

With a docker run command

Steps To Reproduce

Create a bucket with a CORS policy like this:

{
  AllowedOrigins: *,
  AllowedMethods: *,
  AllowedHeaders: ['content-disposition, content-type']
}

and execute a request like this one which is based on a simplified version of a real chrome request:

curl 'http://localhost:4566/bucket'
-X 'OPTIONS'
-H 'Access-Control-Request-Headers: content-disposition, content-type'
-H 'Access-Control-Request-Method: PUT'
-H 'Origin: http://localhost:3000'
-H 'Referer: http://localhost:3000/'

Environment

- LocalStack:
  LocalStack version: 6.4.0

Anything else?

This bug can cause valid CORS preflight requests to be incorrectly rejected if the client omits a space after the comma in Access-Control-Request-Headers, which is allowed by the spec.

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions