How can you debug a CORS request with cURL?

Question

How can you debug CORS requests using cURL? So far I couldn't find a way to "simulate" the preflight request.

Anomaly

Answer 1

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.

Dibranchiate

that page does not seem to return any CORS headers, is that correct? – Nsf

In order to view the actual headers, you need to add the --verbose option, as mentioned above. – Dibranchiate

Hmm, that may be a bug. Can you try the same request to the following url: server.cors-api.appspot.com/… – Dibranchiate

--verbose wasn't displaying headers for me either. I replaced it with "--trace-ascii -" – Involve

or --head: curl -H "Origin: http://example.com" --head https://www.googleapis.com/discovery/v1/apis\?fields\= – Joo

Use --include to see the headers. – Wahl

In 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. – Tender

Answer 2

Use:

curl \
-H "Access-Control-Request-Method: GET" \
-H "Origin: http://localhost" \
--head \
http://www.example.com/

1. Replace http://www.example.com/ with the URL you want to test.
2. 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".

Facies

if 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 'endpoint.com' -H 'Cache-Control: no-cache' --head – Airway

This 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. – Hales

Isn't this backwards? Shouldn't the origin be example.com instead? – Metallic

If the request returns a 404 does it mean anything other than "you got the url wrong"? – Huoh

@Huoh 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. – Shippen

This is probably the best answer out there that solved my problem. Thanks @Vilius! – Jaguar

This can’t be the best answer because it’s wrong: a preflight request is done with OPTIONS, not HEAD or GET. – Cartridge

Answer 3

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.

Cartridge

Answer 4

It seems like just this works:

curl -I http://example.com

Look for Access-Control-Allow-Origin: * in the returned headers.

Merrie

Remember 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. – Donavon

Answer 5

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://mcmap.net/q/80500/-how-can-you-debug-a-cors-request-with-curl

# 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

Amethyst

adding the Origin header would make it better e g. -H 'origin:mydomain.xyz' – Schuster

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. – Cartridge