If everyone agreed that JS code on the internet should be considered public and should never include authenticated content we'd agree 
issue is Function.prototype.toString, which allows you to see the contents of any function. So the exploit is: be aware that 4/
-
-
http://bank.com/account.js contains authenticated, secret account data, <script src="http://bank.com/account.js "> on http://evil.com 5/
-
Now you might be thinking, this seems like an awfully obscure exploit. But if http://bank.com uses a module registry, that 6/
-
<script> will populate a global `__registry__` (or something like it) on *http://evil.com * but with the user's 7/
-
*http://bank.com * cookies. So basically, it's a bad idea to use cookies as auth to put secret content in a JS file. 8/
-
Even if you think you're safe, someone else can decide to switch to webpack and pwn you. So don't do it (put the secret in HTML instead) 9/
-
Given that, when designing <script type="module">, we should certainly *default* away from sending cookies across origins, and maybe 10/
-
we should just say that we provide no sugar for cross-origin credentials for *modules* (and that you'll need to use low-level primitives 11/
-
like Service Worker if you really want to shoot yourself in the foot). F.p.toString is one possible vector of the above vuln 12/
-
but basically anything that lets you hook into JS comings-and-goings is potentially subject to this kind of vuln. 13/13
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.