0

I'm looking at the accepted answer to this question. It recommends the following for making a CORS policy with whitelisted domains:

var whitelist = ['http://example1.com', 'http://example2.com']
var corsOptions = {
  origin: function (origin, callback) {
    if (whitelist.indexOf(origin) !== -1) {
      callback(null, true)
    } else {
      callback(new Error('Not allowed by CORS'))
    }
  }
}

It looks good, but I'm worried about a url like http://example1.com.evil.com. As far as I know, this would be a valid url, and it contains a whitelist string, but it's not a whitelisted domain. Is this method of checking for a domain unsafe, or is there something that prevents a sneaky subdomain from circumventing the CORS policy?

Christopher Waugh
  • 441
  • 1
  • 4
  • 15
  • If you’re not sending cookies/credentials in requests/responses, then there’s no point in setting the Access-Control-Allow-Origin value to a specific origin value. Instead, you should just use `Access-Control-Allow-Origin: *`. See the answer at https://stackoverflow.com/a/43154277/441757. Basically, the only time you want to be setting the Access-Control-Allow-Origin value to anything other than `*` is if you’re including cookies/credentials in the request/response — and in that case, you’d want to be checking the Origin value against a list of allowed Origins (as the snippet in question does) – sideshowbarker Oct 20 '21 at 09:04
  • Setting the Access-Control-Origin value based on the Origin request-header value is only unsafe if 1) you’re not checking the Origin value against an allow list and 2) if the requests include include cookies/credentials, and/or if you’re sending back cookies/credentials in the response *and* sending back an Access-Control-Allow-Credentials response header. But by default browsers do not include cookies in cross-origin requests, and by default your server will not send back an Access-Control-Allow-Credentials response header. – sideshowbarker Oct 20 '21 at 09:11
  • But anyway, the code in the question *is* checking the Origin value against an allow list, and therefore, and so what it’s doing is safe even if the requests do include cookies/credentials, and/or if you’re sending back cookies/credentials in the response *and* sending back an Access-Control-Allow-Credentials response header. – sideshowbarker Oct 20 '21 at 09:14
  • To be clear: by default, browsers don’t include cookies in cross-origin requests, and by default your server won’t send back an Access-Control-Allow-Credentials response header. So unless you’re adding an Access-Control-Allow-Credentials header to the response and/or have frontend code that sends cookies in requests, it’s safe to set the Access-Control-Allow-Origin value based on the Origin value (though, as I wrote in an earlier comment, there’s in that case no point to setting a specific origin value for Access-Control-Allow-Origin; `Access-Control-Allow-Origin: *` is safe in that case). – sideshowbarker Oct 20 '21 at 09:18

0 Answers0