6

TIL that one of the purposes of Cross-Origin-Resource-Sharing - CORS (if not the only) is to secure data saved in the browser for a specific website. Judging from the relevant Wikipedia article, this only applies to HTTP Cookies. Therefore, if I implement CORS on backend, I have to list the specific allowed domains instead of *, because that would effectively create a security vulnerability.

But what if my service does not use browser cookies at all? I have a REST API, where the authorization is done by passing a special header, not relying on cookies in any way. Is it safe in this case to allow any CORS requests with Allow-Origin=* on backend?

Scadge
  • 9,380
  • 3
  • 30
  • 39
  • https://stackoverflow.com/questions/43154170/is-it-safe-to-enable-cors-to-for-a-public-and-readonly-webservice/43154277#43154277 is relevant. But if you’re using any form of credentials — even a custom header that the browser doesn’t recognize as a form of credentials — then in principle that’s basically still in the same class of risk as a request that includes cookies. – sideshowbarker Sep 03 '18 at 14:03
  • I guess it’s worth noting that for cross-origin requests, browsers by default also won’t send the Authorization header. So the risk isn’t strictly just about cookies. See https://fetch.spec.whatwg.org/#ref-for-credentials%E2%91%A6, which says, *“Generally speaking, both sharing responses and allowing requests with credentials is rather unsafe, and extreme care has to be taken to avoid the confused deputy problem.”* https://en.wikipedia.org/wiki/Confused_deputy_problem – sideshowbarker Sep 03 '18 at 14:19
  • @sideshowbarker thanks, it is relevant indeed. But it also says that it is even safe to use `Access-Control-Allow-Origin: *` when cookies or HTTP authorization, since the browser won't send them unless `Access-Control-Allow-Credentials` header is present additionally. I thought that browsers by default add relevant cookies and authorization header when you request the resourse you've already visited, but there's no reason it would do the same for a custom header. That's why I thought using custom header for authorization is safe in this regard. – Scadge Sep 06 '18 at 07:23

0 Answers0