6

Safari seems to drop the Authorization header when following a same-origin 301 redirect. For example, this JS code:

fetch("/api/endpoint-that-redirects", { headers: new Headers({ "Authorization": "sometoken" })})

will trigger one GET to /api/endpoint-that-redirects with the Authorization header, which responds with a 301 w/ Location /api/endpoint. The browser follows this automatically, meaning it makes another GET to /api/endpoint, but this time without the Authorization header.

This seems to be expected behavior when redirecting to a different origin, but I can't see why this would happen if the redirect is to another URL at the same origin.

I've seen a lot of posts online and questions about this behavior on StackOverflow, but I haven't seen any definitive solution or at least an explanation about this behavior. It's also not clear in other questions if the redirect is to the same host.

Chrome (98) and Firefox (97) both follow the redirect and include the Authorization header in the subsequent GET request.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
you786
  • 3,659
  • 5
  • 48
  • 74
  • 1
    The Safari behavior described in the question doesn’t conform to the requirements in the Fetch spec. So it’s a bug in Safari and should be reported in the WebKit/Safari issue tracker at https://bugs.webkit.org/enter_bug.cgi?product=WebKit. Would you be willing to raise an issue for it there? If not, let me know, and I can create an issue for it there myself. – sideshowbarker Mar 02 '22 at 20:59
  • @sideshowbarker, please go ahead and create the issue there. I'd rather not have to create a bugzilla account just for this purpose. Thank you! – you786 Mar 03 '22 at 05:00
  • For the record here, https://stackoverflow.com/users/9961392/lmx opened a Safari bug at https://bugs.webkit.org/show_bug.cgi?id=239944 – sideshowbarker May 02 '22 at 04:58

2 Answers2

3

This is a bug per the Fetch Standard as written. See httpRequest in HTTP-network-or-cache fetch. Each HTTP request essentially starts out with a clone from the input request, which includes all developer-set headers.

However, for the specific case of Authorization it is an open issue whether it shold be included across origins.

Anne
  • 7,070
  • 1
  • 26
  • 27
  • Interesting, thanks for sharing that GH issue! I've upvoted your answer but not sure if I should accept until there's a solution. This behavior is breaking our API clients because we require an `Authorization` header for each request, and we have an internal redirect. – you786 Mar 02 '22 at 18:47
3

Safari 15.4+ (iOS 15.4, macOS 12.3) users will no longer experience this Authorization drop.

Details: A fix for this was actually merged into the WebKit/Safari code back in October 2021 but per comments at https://bugs.webkit.org/show_bug.cgi?id=230935#c18 didn’t end up shipping until mid-March 2022 in Safari 15.4.

So, this problem will continue to happen for any users of Safari versions prior to to 15.4 — users not upgraded to iOS 15.4 or macOS 12.3 yet — but not for users with current Safari/iOS/macOS.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197