CORS defines a way for client web applications loaded in one domain to interact with resources in a different domain. This lets you utilize resources in different buckets across Wasabi accounts for your web applications.
Wasabi’s CORS implementation handles basic cross-origin scenarios but does not perform full CORS validation or return full CORS responses for some request types. We are actively working to expand coverage.
Wasabi maintains a default CORS configuration. Alternatively, you can write a CORS configuration within the Permissions tab of the Bucket Settings. If you define a CORS configuration (described below), the default configuration is overwritten. If you delete a custom CORS configuration, the default configuration is used.
Using the Cross-Origin Resource Sharing (CORS) option, you can configure CORS formatted in JSON by defining a configuration with rules for a bucket. The bucket configuration might include:
Allowed Methods, which are HTTP methods (GET, HEAD, PUT, POST, DELETE, or MOVE) that you want to support for each allowed origin (third-party URL).
Allowed Origins to identify the third-party URLs (the cross-origins) that will be allowed to access your bucket. To grant access to multiple origins, use a comma-separated list or wildcard character (*).
Exposed Headers identify headers in the response to which you want to allow access from the applications.
Defining a CORS Configuration
On the Buckets list, click
for the desired bucket.Click Settings.
Click the Permissions tab.
Click Cross-Origin Resource Sharing (CORS) at the bottom of the screen.
Click Edit.
Enter the CORS configuration. A valid format for the configuration is a JSON array with rules defined as objects. For example:
When you see
you can click Save to create the configuration.
Default CORS Configuration
If the user-defined CORS configuration is not saved in the editor (above), the default CORS configuration is applied to the bucket.