News for hackers. Stuff that matters.

A comment on The Performance Cost of CORS Requests on Single-Page Applications. Parent comment

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.

[ Parent | on HN ]
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.
[ Parent | on HN ]
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.
[ Parent | on HN ]
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.
[ Parent | on HN ]