Configure CORS when a browser application needs to call a PD Cloudflare R2 bucket from another origin. CORS allows the browser interaction; the request still needs valid storage authentication or a valid signed URL.

Review the existing bucket policy

Open the intended service’s Storage settings, choose its bucket and inspect CORS. This module’s simple editor represents one rule. Saving replaces the bucket’s existing CORS configuration with that rule, and clearing origins can remove the configuration. Preserve the required existing policy before replacing it, especially if another administrator configured multiple rules.

Save the intended browser access

1. Add the application’s exact origin, including scheme, hostname and any nonstandard port.
2. Select only its required methods, such as GET for reads or PUT for uploads.
3. Review the available exposed-header and cache settings.
4. Save once, then reopen the bucket’s CORS settings to inspect the result.
5. Test the intended browser request from that origin.

An origin has no URL path. Do not enter a full page address as an origin or broaden to every website just to silence a failed request. A PUT presigned upload needs PUT; selecting POST does not turn R2 into a supported presigned form-upload destination.

Separate CORS from credentials

Inspect the browser’s refused method, origin and requested headers without exposing its signed URL. Confirm the S3 endpoint, current credential and bucket independently. A CORS rule does not make a private object publicly readable and does not replace the service token’s bucket scope.

Cloudflare documents per-bucket CORS. Use that native configuration as a reference while respecting this editor’s one-rule replacement behaviour. If the required policy cannot be represented, have the responsible administrator review it rather than overwriting a working multi-rule configuration.

See the PD Cloudflare R2 WHMCS guide for related tasks, or explore the module.