44

When trying a CORS request on Safari 10.1, on an URL which includes query parameters (e.g. https://example.com/api?v=1), Safari says

XMLHttpRequest cannot load due to access control checks

Chrome/Firefox works fine.

On requests from the page without the ?v=1, Safari works fine too.

I tried changing the server response header from

Access-Control-Allow-Origin: https://example.com

to

Access-Control-Allow-Origin: https://example.com/api?v=1

but that breaks Chrome.

Any suggestions?

kgangadhar
  • 4,886
  • 5
  • 36
  • 54
Marius
  • 1,659
  • 3
  • 22
  • 31
  • try with `encodeURI('https://example.com/api?v=1')` – Tushar Gupta Apr 20 '17 at 10:45
  • tried, no change: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://test.com/page?v=1' that is not equal to the supplied origin. Origin 'https://test.com' is therefore not allowed access. – Marius Apr 22 '17 at 06:37
  • I have the same issue with Safari when running a site locally. – Gaz Jul 11 '17 at 08:34
  • Did any of you find a solution @Gaz or Marius? – swenedo Aug 16 '17 at 14:04
  • Apparently having the same problem here. Do we just disable use of query parameters to keep Safari happy? – ebyrob Sep 20 '17 at 20:55
  • Have you read this post?: https://discussions.apple.com/message/31846683#31846683 the reply is curious, due to malware? i don't have MAC but sounds strange – Kalamarico Oct 08 '17 at 21:32
  • 4
    access-control-allow-origin is a bit dizzy... could you please specify cleanly the url where your html page is, the url where the XHR requests contents to and the server where you added access-control-allow-origin to? – user1039663 Nov 15 '17 at 16:37
  • I know it's 8 months late, but have you compared the headers being set in the different scenarios? I ask because of this solution, even though this isn't query string related: https://stackoverflow.com/a/22924272/2133723 Safari was setting some headers that weren't allowed. – Emil Jan 10 '18 at 18:14
  • Or try with `encodeURIComponent(https://example.com/api?v=1)` – c.k Mar 22 '18 at 08:51

6 Answers6

5

You're running into CORS issues.

Some possible causes:

  • The header Access-Control-Allow-Origin can only be set on server side, not in your clients script. (You did not make clear you did that correctly.)
  • Are you sure the protocol (http vs https vs maybe even file) is exactly the same?
  • If you may have multiple sub domains you need to setup your config (e.g. Apache) with something like "^http(s)?://(.+\.)?test\.com$ .
    The ^ marks the start of the line to prevent anything preceeding this url. You need a protocol and allowing both here. A subdomain is optional. And the $ marks the end of line (you don't need to set sub-pages, because origin is only host based).
  • As stated here adding Access-Control-Allow-Headers: Origin to the server configuration as well may be a solution. Try to compare the actual requests made my Safari to the successfull requests done by Firefox or Chrome to spot possible missing Headers as well (and maybe compare them to your server configuration as well).
Seika85
  • 1,981
  • 2
  • 18
  • 29
3

If anyone comes across this error, it just occurred in the application I was building. In my case, it turned out to be a trailing / in the uri, which caused a 301 response, which was for some reason interpreted by Safari as a 500 response.

CinCout
  • 9,486
  • 12
  • 49
  • 67
Christian Kaal
  • 232
  • 3
  • 13
2

Trying following might work - 

Access-Control-Allow-Origin: <origin> | *
mdeora
  • 4,152
  • 2
  • 19
  • 29
1

The problem is because it is necessary to be more specific in the data of the cors this does not happen in the other operating systems that do interpret it

This one worked for me for a back in php

header ("Access-Control-Allow-Headers: X-API-KEY, Origin, X-Requested-With, Content-Type, Accept, Access-Control-Request-Method");
header ("Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE");
header ("Allow: GET, POST, OPTIONS, PUT, DELETE");
$ method = $ _SERVER ['REQUEST_METHOD'];
if ($ method == "OPTIONS") {
     die ();
}
Andersson Mesa
  • 11
  • 1
  • 3
0

Your server needs to reply to the OPTIONS http method. Not only to GET/POST/PUT/DELETE. Safari silently requests this hidden in the background. You can discover this with a MITM-attack on the connection, e.g. Fiddler.

The OPTIONS request at least needs to respond with the Cross-Origin Resource Sharing (CORS) headers, e.g.:

  • Access-Control-Allow-Headers
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Origin

Additionally: Your Web Application Firewall (WAF) or Application Security Manager (ASM) needs to allow the OPTIONS request to pass through to your server. Often this is blocked by default, because it gives some slivers of information about the attack surface variables (http methods & headers) used by your API.

Henk Poley
  • 729
  • 8
  • 17
-4

You should check the method type you calling may be - PUT, POST, GET etc.

Madan Dale
  • 43
  • 3