A CORS preflight request obviously uses the OPTIONS method and has an Origin header. However, a browser can decide for any HTTP request to add an Origin header. Also, OPTIONS may be used for other functionality than CORS. (How) Can I identify exactly (without false positives or negatives) whether a request is a CORS preflight request?
相关问题
- firebase storage cors strange Behaviour
- How do I add CORS to a compojure-api app?
- CORS issue with Twitter api calls in Webpack dev s
- CORS errors when trying to fetch from new Google C
- Access to XMLHttpRequest at '…' from origi
相关文章
- Security concerns about CORS
- Configure Spring for CORS
- subdomain CORS in webApi 2
- CORS request did not succeed on Firefox but works
- Run Angular and ASP.NET Web API on the same port
- CORS on Symfony 2 errors BeSimpleSOAPBundle callin
- CORS rules coversion from Apache .htaccess to ngin
- Security for cross-origin resource sharing
Check for the Access-Control-Request-Method header. It would not make much sense to send it in a request other than the preflight request.
Check for the existence of these essential information present in a preflight request:
OPTIONS
Origin
headerAccess-Control-Request-Method
header, indicating what's the actual method it's trying to use to consume your service/resourceConsiderations
In theory you you could be a so clever and manually set those headers and try to make some fake-Preflight request for some reason.
However, your browser would complain with the following sample message:
Refused to set unsafe header "Origin"
(tested as an XHR request on Chrome) while other apps, such as Postman will set their ownOrigin
as, sayOrigin: chrome://extension...