In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed.

If you can break same origin policy submit a bug to Google. That would be a significant defect that would warrant their top tier bug bounty.

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

If the app code goes over HTTP, it makes zero difference if you send data or not in your app. Not exactly the same scenario, but very close to my point is a situation a while back where JavaScript was injected into non-SSL web traffic that was used to DDoS Github[0].

Seriously, use HTTPS for everything. Not to be rude at all (seriously!), but it’s pretty obvious by this thread and the other you linked to that you don’t have the knowledge/experience on this topic, so do your users a favor and trust when I say you need to be using HTTPS.

[0] https://www.theregister.co.uk/2015/03/27/github_under_fire_f...

There is no user data crossing the wire. You are instead sending code that the user will execute. An attacker can substitute literally any code they wish. This new code can collect user data and send it over the wire literally anywhere.

SOP offers zero protection against this. Just load evil.com?data=XYZ in an iframe.

Like this? https://news.ycombinator.com/item?id=17861667

> Others on here have attempted examples, but they have all failed.

Where? I’m happy to prove the attack vector if necessary, would be trivial for me to do if the app is designed the way you described it (and no, not eligible for any Google bounty as this has nothing to do with same origin policy).