CORS request validation

Content Platform Tenant Management Help

Version
9.7.x
File Size
4269 KB
Audience
anonymous
Part Number
MK-95HCPH002-19

After CORS rules are configured for an HCP namespace, web applications can request access to the namespace resources by using either the Hitachi API for Amazon S3 or the REST API.

The Amazon S3 and REST gateways perform CORS rules validation on incoming object requests against an HCP bucket. When a CORS compliant HCP server receives a bucket request from a browser, the server evaluates the request headers against the CORS rules configuration for the bucket. The first CORS rule for the bucket that matches the request is the rule that is applied for creating the server response headers.

For security reasons, requests that fail authentication are not validated. In the web browser, these failed authentication requests result in CORS errors.

Runtime request headers

Request headers are automatically set when a web browser issues an HTTP request to an HCP server.

The following list describes the runtime request headers sent by a browser depending on the request type (simple or preflight).

Origin
Request type: Simple, Preflight
Origin of the cross-domain request. For example, http://www.example.com
Access-Control-Request-Method
Request type: Preflight
HTTP method to be used when the request is made.
Access-Control-Request-Headers
Request type: Preflight
Headers used when the request is made. The format for the headers is a comma-separated list. If any of the headers are not contained in a CORS rule, the preflight request and CORS access to the server are denied, and the subsequent request is not issued.

Runtime response headers

In response to a CORS simple or preflighted request from the browser, the HCP server responds with the corresponding CORS headers.

The following list describes the CORS response headers.

Access-Control-Allow-Origin
Request type: Simple, Preflight
This response header indicates whether the response can be shared with the requesting code from the origin.
If no applicable CORS rule is defined on the server, the Access-Control-Allow-Origin header is not defined in the response, which causes the browser to deny access to the resource.
A '*' wildcard character by itself means that the resource is public and available to everyone. Using '*' as the value of this header with credentials will result in an error. For more information, see the Access-Control-Allow-Credentials response header description in this table.
Access-Control-Allow-Headers
Request type: Preflight
Returned by the server in response to a preflight request that includes the Access-Control-Request-Headers header to indicate which HTTP headers can be used during the actual request.
Only returned for the OPTIONS request, not for the preflighted API call.
Access-Control-Allow-Methods
Request type: Preflight
Returned by the server in response to a preflight request to specify the HTTP method or methods allowed when the actual request is made.
Only returned for the OPTIONS request, not for the preflighted API call.
Access-Control-Expose-Headers
Request type: Simple, Preflight
Optional
Headers that browsers are allowed to access. By default, only six simple response headers are exposed:
  • cache-control
  • content-language
  • content-type
  • expires
  • last-modified
  • pragma
Only returned for the OPTIONS request, not for the preflighted API call.
Access-Control-Max-Age: delta-seconds
Request type: Preflight
Optional
Indicates how long the results of a preflight request can be cached in the browser.
Access-Control-Allow-Credentials: true
Request type: Simple, Preflight
Optional
When used in a response to a preflight request, this header indicates whether the actual request can be made with credentials.
For a simple request, if the header is true, the response is ignored by the browser and no content is returned to the web browser. This header works in conjunction with the credentials option (XHR or Fetch request).
HCP returns the true value for this header unless the AllowedOrigin element in the CORS rules configuration is defined as "*"; in the latter case, the Access-Control-Allow-Credentials header is not returned.
Note: A CORS compliant HCP server will not return the Access-Control-Allow-Credentials header when the wildcard character "*" is defined as Allow-Origin and the value of the Access-Control-Allow-Origin response header is "*".
Vary
Request type: Simple, Preflight
This response header determines how to match future request headers to determine whether a cached response can be used rather than requesting a new response from the server.
If the HCP server sends a response with an Access-Control-Allow-Origin value that is an explicit origin (rather than the wildcard character "*"), the response should also include a Vary response header with the Origin value to indicate that server responses can differ based on the value of the Origin request header.
The value of the Vary header is a comma separated list of header names that can change. For example:
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method

Example: Preflighted request

Here is an sample CORS preflighted request.

The preflighted request comprises two exchanges: an HTTP OPTIONS request (preflight request) from a web browser in one domain to a server in another domain to determine whether the actual request is safe to send, followed by the actual request.

Request headers (Preflight request)

OPTIONS rest/file.txt HTTP/1.1
Host: finance.europe.hcp.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.96 Safari/537.36
Access-Control-Request-Headers: Authorization
Access-Control-Request-Method: GET
Origin: http://lgreen.example.com
Referer: http://lgreen.example.com/cors/rest.html

Response headers (Preflight request)

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Methods: GET, PUT, DELETE, POST, HEAD
Access-Control-Allow-Origin: *
Cache-Control: no-cache,no-store,must-revalidate
Content-Length: 0
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'self'; frame-ancestors 'self';
Date: Tue, 07 May 2019 14:45:08 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Strict-Transport-Security: max-age=31536000; includeSubDomains
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

In this example, the first exchange is complete. The server evaluated the preflight request against the CORS rules configuration for the resource, and responded that it is acceptable for the browser to send the actual request parameters: a GET request to a bucket named finance for an object named rest/file.txt.

Request headers (Actual request)

GET rest/file.txt HTTP/1.1
Host:finance.europe.hcp.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.96 Safari/537.36
Origin:http://lgreen.example.com

Response headers (Actual request)

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://lgreen.example.com
Access-Control-Expose-Headers: ETag

Response body (Actual request)

[contents of the rest/file.txt object]