Cross-Origin Resource Sharing

Enable Cross-Origin Resource Sharing (CORS) in the Object Store service on AWS-based landscapes.

CORS allows web applications to access resources from a different origin. By configuring CORS rules on an Object Store bucket, you can control which origins, HTTP methods, and headers are permitted to access the stored objects.

The CORS configuration is only supported on the standard plan. When a service instance is deleted, any CORS configuration set up on the bucket is automatically removed.

Security Guidelines

Object Store does not validate or restrict the values passed in the corsPermissions configuration. You are responsible for ensuring that the configuration contains only legitimate and intentional values.

Follow these guidelines to reduce security risks:
  • Only add to the allowlist origins, headers, and methods from known and trusted sources. Unverified origins could expose your data to unauthorized cross-origin access.

  • Avoid using wildcard (*) origins.

  • Allow only the HTTP methods your application needs. Avoid enabling write methods (POST, PUT, DELETE) for origins that only require READ access.

  • Specify allowed headers clearly instead of using a wildcard (*) to avoid sensitive or unexpected requests.

Enable or Update CORS

To configure CORS, pass the corsPermissions parameter as an array of one or more CORS rule objects when you create or update an instance.

The corsPermissions array accepts one or more rule objects. Using corsPermissions replaces the entire existing CORS configuration on the bucket. When adding a new rule to an existing setup, include all existing rules alongside the new one in the same array.

Each rule object can contain the following fields:

Field

Type

Required

Description

allowedMethods

Array of strings

Yes

The HTTP methods permitted for cross-origin requests. Accepted values are:

  • GET

  • PUT

  • POST

  • DELETE

  • HEAD

allowedOrigins

Array of strings

Yes

The origins allowed to make cross-origin requests.

List specific origin URLs or use a wildcard (*) to allow all origins.

allowedHeaders

Array of strings

No

The request headers allowed in a cross-origin request.

Use a wildcard (*) to allow all headers.

exposeHeaders

Array of strings

No

The response headers that can be exposed to the browser. For example: x-amz-server-side-encryption, x-amz-request-id, x-amz-id-2.

maxAgeSeconds

Integer

No

The duration, in seconds, that the browser can cache a preflight response.

An example of a single rule object:
"corsPermissions": [
    {
      "allowedMethods": ["GET", "PUT", "POST", "DELETE", "HEAD"],
      "allowedOrigins": ["https://example.com"],
      "allowedHeaders": ["*"],
      "exposeHeaders": ["x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2"],
      "maxAgeSeconds": 3000
    }
  ]
​To enable or update CORS on an existing service instance, use the following command:
cf update-service <service_instance_name> -c '{
  "corsPermissions": [
    { <rule-1> },
    { <rule-2> },
    ...
  ]
}'

For more information on creating, retrieving, and updating parameters, see Configuring Parameters of an Object Store Instance.

Disable CORS

To disable CORS on an existing service instance, pass null as the value for corsPermissions. The command will remove all CORS rules configured on the bucket.
cf update-service <service_instance_name> -c '{"corsPermissions": null}'

View the CORS Configuration on a Service Landscape

The following command retrieves the current CORS configuration with other instance parameters:
cf service <service_instance_name> --params
An example response of when CORS is configured:
{
  "preventDeletion": false,
  "versioning": true,
  "corsPermissions": [
    {
      { <rule-1> },
      { <rule-2> },
      ...
    }
  ]
}