How can you debug CORS requests using cURL? So far I couldn't find a way to "simulate" the preflight request.
5 Answers
Here's how you can debug CORS requests using curl.
Sending a regular CORS request using cUrl:
curl -H "Origin: http://example.com" --verbose \
https://www.googleapis.com/discovery/v1/apis?fields=
The -H "Origin: http://example.com"
flag is the third party domain making the request. Substitute in whatever your domain is.
The --verbose
flag prints out the entire response so you can see the request and response headers.
The URL I'm using above is a sample request to a Google API that supports CORS, but you can substitute in whatever URL you are testing.
The response should include the Access-Control-Allow-Origin
header.
Sending a preflight request using cUrl:
curl -H "Origin: http://example.com" \
-H "Access-Control-Request-Method: POST" \
-H "Access-Control-Request-Headers: X-Requested-With" \
-X OPTIONS --verbose \
https://www.googleapis.com/discovery/v1/apis?fields=
This looks similar to the regular CORS request with a few additions:
The -H
flags send additional preflight request headers to the server
The -X OPTIONS
flag indicates that this is an HTTP OPTIONS request.
If the preflight request is successful, the response should include the Access-Control-Allow-Origin
, Access-Control-Allow-Methods
, and Access-Control-Allow-Headers
response headers. If the preflight request was not successful, these headers shouldn't appear, or the HTTP response won't be 200.
You can also specify additional headers, such as User-Agent
, by using the -H
flag.

- 30,738
- 21
- 105
- 131

- 45,581
- 16
- 101
- 95
-
2that page does not seem to return any CORS headers, is that correct? – Janus Troelsen Feb 24 '13 at 20:01
-
1In order to view the actual headers, you need to add the `--verbose` option, as mentioned above. – monsur Feb 25 '13 at 14:24
-
Hmm, that may be a bug. Can you try the same request to the following url: http://server.cors-api.appspot.com/server?id=3349374&enable=true&status=200&credentials=false&methods=GET%2CPOST&headers=X-Requested-With – monsur Feb 25 '13 at 15:41
-
1--verbose wasn't displaying headers for me either. I replaced it with "--trace-ascii -" – Bryan Larsen Sep 30 '13 at 15:00
-
12or `--head`: `curl -H "Origin: http://example.com" --head https://www.googleapis.com/discovery/v1/apis\?fields\=` – John Bachir Apr 06 '14 at 05:30
-
3Use --include to see the headers. – Mika Tuupola Feb 18 '16 at 16:18
-
9In the case of S3, the according headers are only added if the proper method is given, you can do so by using `curl -H "Access-Control-Request-Method: GET" -H "Origin: http://example.com" -I https://s3.amazonaws.com/your-bucket/file`. – Joscha Mar 02 '16 at 02:13
Use:
curl \
-H "Access-Control-Request-Method: GET" \
-H "Origin: http://localhost" \
--head \
http://www.example.com/
- Replace http://www.example.com/ with the URL you want to test.
- If the response includes
Access-Control-Allow-*
then your resource supports CORS.
Rationale for the alternative answer
I google this question every now and then and the accepted answer is never what I need. First, it prints the response body which is a lot of text. Adding --head
outputs only headers. Second, when testing S3 URLs we need to provide additional header -H "Access-Control-Request-Method: GET"
.

- 33,193
- 69
- 233
- 372

- 3,121
- 3
- 24
- 24
-
2if I curl without setting origin and I can get response and headers(including access-control-allow-origin header) back, does that mean I set up my CORS incorrectly? curl -X GET 'https://www.endpoint.com' -H 'Cache-Control: no-cache' --head – Jun Jul 13 '18 at 00:23
-
3This relies on `--head` making curl print out the headers, but it also makes curl make a `HEAD` request rather than a `GET`. Depending on what you're testing, you may want to make a `GET` request. You can do this by adding `--IXGET`. – Aidan Fitzpatrick Dec 05 '18 at 16:11
-
3Isn't this backwards? Shouldn't the origin be example.com instead? – Dustin Ingram Apr 22 '19 at 18:43
-
If the request returns a 404 does it mean anything other than "you got the url wrong"? – jcollum Sep 23 '21 at 16:16
-
@jcollum yes; you might have got the URL wrong, but it might also be that the URL is correct but the resource is not there (outdated?); or that is there but is not reachable, for some reason (bug in the routing? in the load-balancer rules? etc.). – By the way, issues with CORS would return a 403. – Kamafeather Aug 16 '22 at 22:50
-
This is probably the best answer out there that solved my problem. Thanks @Vilius! – captainblack Sep 08 '22 at 07:21
-
This can’t be the best answer because it’s wrong: a preflight request is done with `OPTIONS`, not `HEAD` or `GET`. – bfontaine Sep 28 '22 at 09:29
The preflight request is done using the OPTIONS
HTTP method.
Assuming you want to test CORS on a POST request from http://mysite.example.com to https://myapi.example.com/foo, the command should be:
curl -XOPTIONS \
-H "Access-Control-Request-Method: POST" \
-H "Origin: http://mysite.example.com" \
https://myapi.example.com/foo
The response is either OK
or an error message like Disallowed CORS origin. You can still include the headers using -i
if you’d like.
This is a lot simpler than some other responses that make either GET or HEAD requests and ask you to interpret the headers.

- 30,738
- 21
- 105
- 131

- 18,169
- 13
- 73
- 107
It seems like just this works:
curl -I http://example.com
Look for Access-Control-Allow-Origin: *
in the returned headers.

- 30,738
- 21
- 105
- 131

- 2,807
- 2
- 29
- 38
-
7Remember that `*` doesn't work if credentials such as a cookie need to be presented with the API request. In that case the FQDN is required in the `Access-Control-Allow-Origin` response as well as `Access-Control-Allow-Credentials: true`. Credentialed requests though weren't specified as a requirement by OP, so `*` works for any unauthenticated requests. – GameSalutes Jan 30 '19 at 18:04
The Bash script "corstest" below works for me. It is based on Jun711's comment.
Usage
corstest [-v] URL
Examples
./corstest https://api.coindesk.com/v1/bpi/currentprice.json
https://api.coindesk.com/v1/bpi/currentprice.json Access-Control-Allow-Origin: *
The positive result is displayed in green:
./corstest https://github.com/IonicaBizau/jsonrequest
https://github.com/IonicaBizau/jsonrequest does not support CORS
You might want to visit https://enable-cors.org/ to find out how to enable CORS
The negative result is displayed in red and blue.
The -v option will show the full curl headers.
corstest
#!/bin/bash
# WF 2018-09-20
# https://stackoverflow.com/a/47609921/1497139
# ANSI colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'
red='\033[0;31m'
green='\033[0;32m' # '\e[1;32m' is too bright for white background.
endColor='\033[0m'
#
# A colored message
# parameters:
# 1: l_color - the color of the message
# 2: l_msg - the message to display
#
color_msg() {
local l_color="$1"
local l_msg="$2"
echo -e "${l_color}$l_msg${endColor}"
}
#
# Show the usage
#
usage() {
echo "usage: [-v] $0 url"
echo " -v |--verbose: show curl result"
exit 1
}
if [ $# -lt 1 ]
then
usage
fi
# Commandline option
while [ "$1" != "" ]
do
url=$1
shift
# Optionally show usage
case $url in
-v|--verbose)
verbose=true;
;;
esac
done
if [ "$verbose" = "true" ]
then
curl -s -X GET $url -H 'Cache-Control: no-cache' --head
fi
origin=$(curl -s -X GET $url -H 'Cache-Control: no-cache' --head | grep -i access-control)
if [ $? -eq 0 ]
then
color_msg $green "$url $origin"
else
color_msg $red "$url does not support CORS"
color_msg $blue "you might want to visit https://enable-cors.org/ to find out how to enable CORS"
fi

- 30,738
- 21
- 105
- 131

- 15,016
- 11
- 93
- 186
-
1adding the Origin header would make it better e g. *-H 'origin:https://mydomain.xyz'* – Bas Mar 16 '20 at 21:32
-
I downvoted because 1- 99% of this script is irrelevant to the answer; 2- the command used in the script is the same as the accepted answer written 6 years before; 3- that command is wrong: preflight requests use `OPTIONS`, not `GET` nor `HEAD`. – bfontaine Sep 28 '22 at 09:36