OPTIONSrequest method, and then, upon approval from a server, sending the actual request.
OPTIONSmethod to a resource on an other domain, to determine if an actual request is safe to send.
Access-Control-Allow-Originheader, instead of specifying the
XMLHttpRequestcapability do not have to set any CORS headers programmatically.
Originheader indicates an origin of a cross-site access request or preflight request. The
originparameter is a URI indicating a server from which the request initiated. It does not include any path information, but only a server name.
Access-Control-Request-Methodis used when issuing a preflight request to let a server know what HTTP method will be used when an actual request is made.
Access-Control-Request-Headersheader is used when issuing a preflight request to let a server know what HTTP headers will be used when an actual request is made.
Access-Control-Allow-Originspecifies either a single origin (or null), which tells browsers to allow that origin to access a resource. For requests without credentials - the
'*'wildcard, to tell browsers to allow any origin to access a resource.
'*'wildcard, a server should also set
Originin the Vary response header - to indicate to clients that server responses will differ based on the value of the
Access-Control-Allow-Methodsheader specifies a method or methods allowed when accessing a resource. This is used in response to a preflight request.
Access-Control-Allow-Headersheader is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.
Access-Control-Expose-Headersheader lets a server whitelist headers that browsers are allowed to access. By default, browsers have access to only the 7 CORS-safelisted response headers:
Access-Control-Max-Ageheader indicates how long results of a preflight request can be cached.
http://trusted-subdomain.vulnerable-website.comas an origin
Originheader, but some parse it as a URL instead. This allows you to exploit the browser's tolerance for unusual characters in domain names.
https://website.com%60.attacker.com/is a valid URL. If a CORS request originating from that URL, the
Originheader will look like next one:
_character in subdomains, that can be used instead of
`to exploit Firefox and Chrome users.
subdomain.vulnerable-website.comcould use that to retrieve an API key using a URL like:
Access-Control-Allow-Originwhen credentials flag is true, check Access-Control-Allow-Origin, many applications programmatically generate the
Access-Control-Allow-Originheader based on the user-supplied
Originvalue. If you see a HTTP response with any
Access-Control-*headers but no origins declared, this is a strong indication that an application will generate the header based on a user input. Other applications will only send CORS headers if they receive a request containing the
Originheader, making associated vulnerabilities extremely easy to miss.
Originheader without even checking it for illegal characters like , you have a HTTP header injection vulnerability against IE/Edge users, because IE and Edge view
\r (0x0d)as a valid HTTP header terminator:
Originheader supports the value
null. Browsers might send the value
Originheader in various unusual situations:
nullorigin to support local development of the application.
Originheader. This will satisfy the whitelist, leading to cross-domain access. For example, this can be done using a sandboxed iframe cross-origin request of the form:
Varyresponse header whenever
Access-Control-Allow-Originheaders are dynamically generated.
Vary: Originhas not been specified the response may be stored in the browser's cache and displayed directly when the browser navigates to the associated URL.