Cross-Origin Resource Sharing
Tizen supports the mechanism of cross-origin resource sharing (CORS), which can activate a client-side cross-origin request (COR).
In CORS, new headers related to HTTP communication have been added to allow you to accept or reject CORs:
-
Origin request header
Includes the domain information which has incurred the COR, and is used for the purpose of checking the source of the domain side that has received the relevant request. In addition, this header is protected in the browser side and cannot be changed from the application side.
-
Access-Control-Allow-Origin response header
Allows a relevant response only when the information in the Origin request header matches. If the Access-Control-Allow-Origin header is a wildcard (*), it unconditionally allows the response regardless of the Origin request header information.
Note If an extremely allowable CORS policy is used, it can lead to spoofing, data stealing, relay, and other attacks through communication with malicious application programs. To avoid unexpected consequences, pay attention when defining the response header.
CORS supports 2 request types: simple and preflight.
Simple Request
The request is considered to be a simple request, if all the conditions following conditions are met:
- HTTP methods can only use GET, POST, and HEAD.
- No custom header is allowed.
- The Content-Type is one of the following:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
When using simple requests, the response is set in the server side with the following response headers:
- Access-Control-Allow-Origin (mandatory)
- Access-Control-Allow-Credentials (optional)
- Access-Control-Expose-Headers (optional)
Figure: Simple request workflow
Preflight Request
If a request is not a simple request, it is considered to be a preflight (non-simple) request, which is case-insensitive.
If the access authority is allowed through the preflight request, the actual request for sending the actual data is made. The preflight request can allow access based on various standards other than Origin, such as HTTP certification, HTTP method (for example, GET, POST, or PUT…), or the existence of a certain header.
When using preflight requests, the response is set in the server side with the following response headers:
- Access-Control-Allow-Origin (mandatory)
- Access-Control-Allow-Methods (mandatory)
- Access-Control-Allow-Headers (mandatory, if a custom header is used)
- Access-Control-Allow-Credentials (optional)
- Access-Control-Expose-Headers (optional)
- Access-Control-Max-Age (optional)
Figure: Preflight request workflow