mc cors
mc cors manages per-bucket Cross-Origin Resource Sharing (CORS) in SILO. Per-bucket CORS is available from SILO 20260903; the presence of the client command does not imply that an older server implements bucket rules.
Commands and permissions
set reads XML from a file or standard input (-) and replaces the bucket’s complete CORS document. get displays the current configuration; remove deletes it.
All three subcommands support global flags and have no additional command-specific flags.
| Command | Required SILO policy action |
|---|---|
mc cors set |
s3:PutBucketCors |
mc cors get |
s3:GetBucketCors |
mc cors remove |
s3:DeleteBucketCors |
Grant these actions on a bucket resource, such as arn:aws:s3:::mybucket.
Example configuration
This configuration lets browsers at https://app.example.com read objects and access the response’s ETag header:
The document is limited to 64 KiB and must contain 1 to 100 rules, each with at least one AllowedOrigin and AllowedMethod.
Allowed methods are GET, PUT, HEAD, POST, and DELETE; do not list the preflight method OPTIONS.
Each AllowedOrigin and AllowedHeader value may contain at most one *, and must not use the ? wildcard.
Behavior
When a bucket has a CORS configuration, only its rules apply: a nonmatching rule does not fall back to a broader global policy. After removal, a loaded bucket with no CORS document uses the global MINIO_API_CORS_ALLOW_ORIGIN / api cors_allow_origin setting. Removing the document therefore does not deny all cross-origin requests.
Buckets not yet loaded during startup, buckets whose metadata failed to load, and invalid bucket configurations do not fall back to the global policy to relax access. CORS preflight and response headers do not grant S3 permissions; an actual object request still needs an anonymous policy, valid credentials, or a presigned URL.
Per-bucket CORS is synchronized by site replication and preserved by mc admin cluster bucket export and import. See the CORS and replication trust boundary for implementation details.