Cross Origin Requests
- What is HTTP Cross Origin Request?
When a HTTP client like Browser makes an AJAX requests of a resource from a different domain.
For example:
An HTML page served from http://Example.com makes an <img> src request for http://HelloWorld.com/image.jpg. - What are the Potential Security Concerns with COR?
Universal Allow, Site-level Cross Origin Access, Access-control decision based on Origin header, Prolonged caching of Preflight responses, Misplaced-trust, Processing rogue COR.
3) What are Simple HTTP Cross Origin Requests?
GET, POST and HEAD
4) What Browser does for simple HTTP Cross Origin Requests?
It simple checks the response header.
If the response header contains “Access-Control-Allow-Origin”: ”<Either same domain name> or *” then Browser provides the data to the callback function.
If the response header doesn’t contain “Access-Control-Allow-Origin” attribute then the data will be empty.
5) What are Preflighted or Not-so-Simple HTTP Cross Origin Requests?
If the request uses methods other than following:
GET,HEAD, POST
Apart from the headers set automatically by the user agent, the request includes any headers other than those which the Fetch spec defines as being a “CORS-safelisted request-header
6) Which Browsers support this Preflighted requests?
Most browsers currently don’t support following redirects for preflighted requests.
Chrome supports it but IE doesn’t. For IE, PUT was a simple Cross origin request.
7) How a preflighted requests are handled by a Browser which supports it(Like Chrome)?
Whenever there is a Not-so-Simple HTTP Request like PUT or DELETE, the browser first send an HTTP Packet to the requested domain with method OPTIONS.
So your server first gets an OPTIONS request with some headers.
“Access-Control-Request-Method” : “PUT”
“Access-Control-Request-Headers” : “Some value”
The Access-Control-Request-Method header notifies the server as part of a preflight request that when the actual request is sent, it will be sent with a PUT request method.
The Access-Control-Request-Headers header notifies the server that when the actual request is sent, it will be sent with a X-PINGOTHER and Content-Type custom headers.
The server now has to set some headers while responding to the OPTIONS request.
“Access-Control-Allow-Origin” : “same domain name”
“Access-Control-Allow-Methods” : “PUT,DELETE”
“Access-Control-Allow-Headers” : ”Some value”
When browser receives this response, then it actually sends the original PUT request.