What CORS settings are required for browser-based uploads?

What CORS settings are required for browser-based uploads?

Browser-based uploads to R2 cross origins when the application and storage use different hostnames. CORS tells the browser which cross-origin interactions the storage service permits. The policy must match the requests the application actually sends.

Match origins, methods, and request headers

For a presigned PUT upload, allow the intended application origin and the PUT method. Include request headers such as Content-Type when the client sends them. Origins include the scheme and host, plus a port when relevant.

Keep localhost development origins in the development configuration. Add the actual production custom domain to production rules. R2's CORS documentation explains these settings and optional response-header exposure.

Keep the upload request consistent with its signature

If signing includes a specific Content-Type header, send that same value during the upload. A mismatch can fail signature validation even when CORS is otherwise correct.

Use only the methods and headers the workflow needs. If browser code must read a response header such as ETag, expose that header explicitly. Do not treat an exposed ETag as universal proof that image content is valid.

Diagnose browser failures without weakening authorization

Inspect the preflight and upload requests separately. Check the requested origin, method, headers, and whether the URL is still valid. A browser error can obscure a storage rejection, so correlate it with safe server-side diagnostics.

CORS is not a wedding-membership check and does not stop every nonbrowser client from making requests. Keep storage private as intended and require backend authorization before granting upload access. Test allowed and disallowed browser origins alongside unauthorized application requests. A working policy should enable the approved gallery flow without pretending to replace authentication or file verification.