A browser PUT to an S3 presigned URL fails with a CORS error in the developer console, yet the same URL works from curl. What is actually wrong, and what do you configure to fix it?

## Why curl works and the browser does not CORS has no bearing on whether S3 will accept a request. It is a rule enforced *by the browser*, protecting one origin's script from silently reading another origin's responses. `curl` implements no such rule, so a presigned URL that works there proves the signature, the expiry and the signing principal's permissions are all fine. When the page fails anyway, the missing piece is the bucket's CORS configuration. ## The preflight A cross-origin `fetch` with method `PUT`, or with a `Content-Type` outside the small "simple" set, is not sent directly. The browser first issues: ``` OPTIONS /uploads/abc123.png HTTP/1.1 Origin: https://app.example.com Access-Control-Request-Method: PUT Access-Control-Request-Headers: content-type ``` Two things about that request surprise people. It carries **no signature** — the query-string authentication is not part of a preflight — and it is anonymous. So S3 answers it purely from the bucket's CORS configuration; policy and signature play no part. If no rule matches the `Origin` and the requested method, the response lacks `Access-Control-Allow-Origin`, and the browser reports a CORS failure and never sends the PUT. The console message is about CORS, but the network tab shows an `OPTIONS`, not the upload — that is the diagnostic. ## The configuration CORS lives on the bucket as a small JSON document of rules: ```json [ { "AllowedOrigins": ["https://app.example.com"], "AllowedMethods": ["PUT", "GET", "HEAD"], "AllowedHeaders": ["content-type", "x-amz-*"], "ExposeHeaders": ["ETag"], "MaxAgeSeconds": 3000 } ] ``` Field by field: - **AllowedOrigins** must match the page's origin exactly: scheme, host and port. `https://app.example.com` does not cover `http://app.example.com`, `https://www.app.example.com`, or `http://localhost:3000` during development. A wildcard is accepted but is a poor idea for an upload bucket. - **AllowedMethods** is a fixed vocabulary of HTTP methods; `PUT` for uploads, `GET`/`HEAD` for reads, `POST` for policy-form uploads, `DELETE` if the client deletes. - **AllowedHeaders** must list every header your code sets on the request. Forgetting `content-type` is the single most common cause of a preflight rejection that looks like an origin problem. - **ExposeHeaders** controls what JavaScript may *read* from the response. By default a cross-origin response exposes almost nothing, so `response.headers.get('ETag')` returns `null` unless `ETag` is listed here — which matters when your code needs the returned entity tag after an upload. - **MaxAgeSeconds** lets the browser cache the preflight result, so you are not paying an extra round trip per upload. ## Two things it is not **CORS is not authorization.** A wide-open CORS configuration does not make a private bucket readable; every request still needs a valid signature or a policy that allows it. Conversely, tightening CORS is not a security control against non-browser clients — it does nothing to curl, a script, or a mobile app. **CORS is not the answer to every browser-side 403.** If the network tab shows the actual `PUT` reaching S3 and returning 403, CORS is not your problem — you are looking at a signature mismatch, an expired URL or a permissions failure. A useful discriminator: a genuine CORS block means the real request was never sent. ## The other classic near-miss Adjacent to CORS, and often mistaken for it, is a signed-header mismatch. If you presigned with `Content-Type` among the signed headers, the browser must send exactly that value; a `fetch` that omits it, or lets the browser infer a different one from a `Blob`, produces `SignatureDoesNotMatch`. That failure returns a real HTTP response from S3, so with CORS configured you will see a 403 in the network tab rather than a CORS message — which is precisely how you tell the two apart. ## In an interview Say it in one line: "CORS is enforced by the browser, so curl succeeding tells me the S3 side is fine. I would add a bucket CORS rule for the exact origin, allow PUT, list the request headers I actually send, and expose ETag if my code reads it."