4 ms·

> JS-initiated requests are not allowed cross-site by default anyway Incorrect. You can use fetch() to initiate cross-site requests as long as you only use the

• duskwuff 2y ago
  And JS can also indirectly initiate requests for resource or page fetches, e.g. by creating image tags or popup windows. It can't see the results directly, but it can make some inferences.
  • 1oooqooq 2y ago
    there are so, so, so many ways to read this data back it's not even fun.
    • Muromec 2y ago
      There are ways, but they generally need a cooperation of both sides of the inter-domain boundary. What you generally can't do is make arbitrary reads from the context of other domain (e.g. call GET on their api and read a result) into your domain without them explicitly allowing it.
      • duskwuff 2y ago
        Right. What you can sometimes do is observe the effects of the content being loaded, e.g. see the dimensions of an image element change when its content is loaded.
        • RandomDistort 2y ago
          Is there some document somewhere that lists all the potential ways of doing stuff like this?
          • Herrera 2y ago
            Yeah, https://xsleaks.dev https://xsleaks.dev tracks most of the known ways to leak cross-origin data.
            • smagin 2y ago
              oh hell yes. And oh yes iframes and postmessages, of course people would setup them incorrectly and even if they do some (probably not that important but still) data will leak if you're creative enough. Thanks for the link!
• deleted 2y ago
  [deleted]
• smagin 2y ago
  you're right, you can initiate cross-site requests that _could be_ form submissions. It was even in the post but I thought I'd omit that bit for clarity. I should have decided otherwise.
• Evidlo 2y ago
  Is that actually true? This SO seems to contradict that: https://stackoverflow.com/questions/44121593/sending-a-simple-post-request-with-jquery-but-getting-cors-anyway#comment75262833_44121649 https://stackoverflow.com/questions/44121593/sending-a-simpl... I just want to fetch publicly available information from my client-side app, but CORS gets in the way and forces me to use a sketchy CORS proxy. Makes me really hate CORS
  • smagin 2y ago
    it is true. But again, writes are allowed, reads are not, you won't be able to see the reply. Which author of the question eventually realised https://stackoverflow.com/a/44122076/1685746 https://stackoverflow.com/a/44122076/1685746
  • reynaldi 2y ago
    I agree with this, but in my past online discussions about fetching publicly available information, two main arguments often arise: 1. The resource owner doesn’t want you fetching their resource. 2. They don’t want to suddenly be flooded with requests. Each of these points has counterarguments. For example, the Same Origin Policy (SOP) only restricts fetches from the client side, and nothing stops people from fetching via a backend. The second argument makes sense, the resource owner doesn’t want their resource to be freely fetched and to suddenly receive thousands of requests that their server likely can’t handle. SOP helps prevent this, but if you’re fetching from the backend, you should implement caching to avoid repeatedly hitting the target resource. I created a CORS proxy [0] to handle this scenario, including caching responses. There are also several free CORS proxies [1] available, they might be considered sketchy, but they’re probably fine for testing. [0] https://corsfix.com https://corsfix.com [1] https://gist.github.com/reynaldichernando/eab9c4e31e30677f176dc9eb732963ef https://gist.github.com/reynaldichernando/eab9c4e31e30677f17...
• klysm 2y ago
  To make things even more complicated, service workers can intercept requests and change the request mode.
  • smagin 2y ago
    oh god you're right https://stackoverflow.com/a/57206146/1685746 https://stackoverflow.com/a/57206146/1685746 yeah sure what can go wrong, let's listen to fetch and modify requests in a service worker.
    • klysm 2y ago
      I actually use this to add authentication headers to images directly via src="". No blob management in javascript :)
• dathinab 2y ago
  Even more funny CORS allow * has very funky interactions as it simplified "doesn't allow the client to provide credentials" (e.g. Authorization header, cookies, etc.). If you have public call-by-JS focused HTTP API which should be accessible from pretty much anywhere and therefore set it to * but also want an `Authorization` header you are in for bad luck. Solution 1. use a custom header for your credentials like e.g. AWS does, works for JS focused APIs but cookies and as such e.g. cookie based XSS protection won't work. Solution 2. dynamically return the callers domain as allowed origin. Works but requires dynamic responses to pre-flight requests and kinda undermines the whole CORS system. honestly neither is really satisfying