> The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.

This was solved a long time ago by marking such cookies as "HTTP only", preventing client-side scripts from reading their values.

Google does mark their account login cookies as both "Secure" (sent only over HTTPS) and "HttpOnly" (not exposed to client-side scripting). You can see this in the server response headers in the browser dev tools' network tab. Even a piece of first-party JavaScript loaded directly from google.com -- even with SRI -- cannot read these cookies for google.com.

▲

michaelt a day ago | parent [-]

> This was solved a long time ago by marking such cookies as "HTTP only"

That stops the attacker from exfiltrating your cookies with their evil JavaScript - but they can still have their script make http requests, and they’ll be made with your cookies.

Or they can throw up a fake login page, which will fool plenty of users because it’s on the right URL, and do what they like with your inputs. Lots of attack options.

	▲	blincoln 10 hours ago \| parent [-]
		This is true, but additionally, the HttpOnly flag is now mostly a relic, because so much web app logic runs in JS in the browser and makes API calls. That code generally needs access to tbe cookies, or something equivalent, like a bearer token.