Put Bucket cors

Last Updated: Apr 17, 2018

With the Put Bucket cors operation, you can set a CORS rule for a specified bucket. If an original rule exists, it is overwritten.

Request syntax

  1. PUT /?cors HTTP/1.1
  2. Date: GMT Date
  3. Content-Length: ContentLength
  4. Content-Type: application/xml
  5. Host: BucketName.oss-cn-hangzhou.aliyuncs.com
  6. Authorization: SignatureValue
  7. <?xml version="1.0" encoding="UTF-8"?>
  8. <CORSConfiguration>
  9. <CORSRule>
  10. <AllowedOrigin>the origin you want allow CORS request from</AllowedOrigin>
  11. <AllowedOrigin>…</AllowedOrigin>
  12. <AllowedMethod>HTTP method</AllowedMethod>
  13. <AllowedMethod>…</AllowedMethod>
  14. <AllowedHeader> headers that allowed browser to send</AllowedHeader>
  15. <AllowedHeader>…</AllowedHeader>
  16. <ExposeHeader> headers in response that can access from client app</ExposeHeader>
  17. <ExposeHeader>…</ExposeHeader>
  18. <MaxAgeSeconds>time to cache pre-fight response</MaxAgeSeconds>
  19. </CORSRule>
  20. <CORSRule>
  21. </CORSRule>
  22. </CORSConfiguration >

Request elements

Name Description Required?
CORSRule CORS rule container. Each bucket allows up to 10 rules
Type: container
Parent node: CORSConfiguration
AllowedOrigin The origins allowed for cross-domain requests. Multiple elements can be used to specify multiple allowed origins. Each rule allows up to one wildcard “*“. If “*“ is specified, cross-domain requests of all origins are allowed.
Type: string
Parent node: CORSRule
AllowedMethod Specify the allowed methods for cross-domain requests.
Type: enumeration (GET, PUT, DELETE, POST, HEAD)
Parent node: CORSRule
AllowedHeader Control whether the headers specified by Access-Control-Request-Headers in the OPTIONS prefetch command are allowed. Each header specified by Access-Control-Request-Headers must match a value in AllowedHeader. Each rule allows up to one wildcard “”
Type: string
Parent node: CORSRule
ExposeHeader Specify the response headers allowing users to access from an application (for example, a Javascript XMLHttpRequest object). The wildcard “*“ is not allowed.
Type: string
Parent node: CORSRule
MaxAgeSeconds Specify the cache time for the returned result of a browser prefetch (OPTIONS) request to a specific resource. The unit is seconds. One CORSRule allows not more than one such parameter.
Type: integer
Parent node: CORSRule
CORSConfiguration CORS rule container of a bucket
Type: container
Parent node: none

Detail analysis

  • CORS is disabled for buckets by default. The origins of all cross-domain requests are forbidden.
  • To use CORS in applications, for example, accessing OSS from www.a.com through the XMLHttpRequest function of browser, you must manually upload a CORS rule through this interface to enable CORS. This rule is described in an XML document.
  • The CORS setting for each bucket is specified by multiple CORS rules. Each bucket allows a maximum of 10 rules. The uploaded XML document cannot be larger than 16 KB.
  • When OSS receives a cross-domain request (or an OPTIONS request), it reads the bucket’s CORS rules and then checks the relevant permissions. OSS checks each rule sequentially and uses the first rule that matches to approve the request and return the corresponding header. If none of the rules match, OSS does not attach any CORS header.
  • Successful CORS rule matching must satisfy three conditions. First, the request Origin must match the AllowedOrigin. Second, the request method (for example, GET, PUT) or the method corresponding to the Access-Control-Request-Method header in an OPTIONS request must match the AllowedMethod. Third, each header contained in the Access-Control-Request-Headers in an OPTIONS request must match the AllowedHeader.
  • If you have uploaded the Content-MD5 request header, OSS calculates the body’s Content-MD5 and check if the two are the same. If the two are different, the error code: InvalidDigest is returned.


Example of adding a bucket CORS rule:

  1. PUT /?cors HTTP/1.1
  2. Host: oss-example.oss-cn-hangzhou.aliyuncs.com
  3. Content-Length: 186
  4. Date: Fri, 04 May 2012 03:21:12 GMT
  5. Authorization: OSS qn6qrrqxo2oawuk53otfjbyc:KU5h8YMUC78M30dXqf3JxrTZHiA=
  6. <?xml version="1.0" encoding="UTF-8"?>
  7. <CORSConfiguration>
  8. <CORSRule>
  9. <AllowedOrigin>*</AllowedOrigin>
  10. <AllowedMethod>PUT</AllowedMethod>
  11. <AllowedMethod>GET</AllowedMethod>
  12. <AllowedHeader>Authorization</AllowedHeader>
  13. </CORSRule>
  14. <CORSRule>
  15. <AllowedOrigin>http://www.a.com</AllowedOrigin>
  16. <AllowedOrigin>http://www.b.com</AllowedOrigin>
  17. <AllowedMethod>GET</AllowedMethod>
  18. <AllowedHeader> Authorization</AllowedHeader>
  19. <ExposeHeader>x-oss-test</ExposeHeader>
  20. <ExposeHeader>x-oss-test1</ExposeHeader>
  21. <MaxAgeSeconds>100</MaxAgeSeconds>
  22. </CORSRule>
  23. </CORSConfiguration >

Response example:

  1. HTTP/1.1 200 OK
  2. x-oss-request-id: 50519080C4689A033D00235F
  3. Date: Fri, 04 May 2012 03:21:12 GMT
  4. Content-Length: 0
  5. Connection: keep-alive
  6. Server: AliyunOSS
Thank you! We've received your feedback.