Re:The Performance Cost of CORS Requests on Single-Page Appl...
by JoachimSchipper on Sunday September 02, 2018 @12:57PM
(#17897615)
Putting a proxy on your own hostname solves the performance problem, but you need something that parses and re-sends requests, not just a general HTTP proxy - otherwise, the third party can e.g. serve malicious Javascript code to your users within your origin.
[ Parent
| on HN ]
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by tootie on Sunday September 02, 2018 @05:20PM
(#17898714)
I'm assuming this is a trusted endpoint. Either something you own or a vendor with a contract. If you're calling random endpoints from your pages, then that's another kettle of fish.
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by JoachimSchipper on Monday September 03, 2018 @02:59PM
(#17904288)
Yes, sorry for writing such a short message - I figured you were probably aware of these considerations, but I was pretty sure that not all your readers were. ;-)
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by yomly on Sunday September 02, 2018 @01:01PM
(#17897635)
Are you able to elaborate further on what attack vector you're thinking of (if only so I can google it) - JSON hijacking maybe?
The implicit assumption being that internally everything trusts the proxy?
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by graystevens on Sunday September 02, 2018 @01:26PM
(#17897751)
I believe they are referring to proxying requests to third parties, rather than the first part of the post which refers to proxying to your own backend.
Proxying requests to a third-party will mean browser security features like CORS will assume they are entirely safe due to them appearing to come from your domain, and not “gist.github.com” etc.
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by dasil003 on Sunday September 02, 2018 @01:05PM
(#17897656)
I'm not following this. In the given example you would configure a proxy to route /api requests to your API cluster. How would an attacker inject a different backend origin?
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by tptacek on Sunday September 02, 2018 @03:16PM
(#17898161)
They wouldn't, but if you proxy arbitrary requests for UnicornGifs.sexy through your CatSharing.com backend, and UnicornGifs.sexy gets owned up (or even just mischievous), it can now generate malicious content in the same origin as CatSharing.com --- the browser can't differentiate which is which. And that forged CatSharing content will be valid in any page on CatSharing.com, not just the specific pages that include it.
The point is that when you serverside-proxy requests to third parties, you're implicitly trusting the third party to control the DOM for any app in your domain.
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by dasil003 on Sunday September 02, 2018 @04:23PM
(#17898455)
Oh right, I missed the last sentence where OP suggested proxying to third parties.
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by krallja on Sunday September 02, 2018 @04:45PM
(#17898548)
How is that different from the unproxied scenario? If unicorngifs.sexy gets pwned, your users get pwned, whether or not there’s a proxy in the middle.
Re:The Performance Cost of CORS Requests on Single-Page Appl...
by wolf550e on Monday September 03, 2018 @09:23AM
(#17902440)
If you load javascript from there - yes, but if you iframe to there - no. You can design a solution that uses cross-origin browser protection to protect your users from getting owned in case a partner is compromised.