So the problem with your examples, and you haven't included the attack surface that allowed for that to happen. (With the exception of XSS, which can only be executed through an interaction from the user's user agent. But to be specific, take the "compromised third-party JS library" example. You've made it specific to the browser with "the addition of a script tag", which is good, but you've left out how that happens. But how did it get there exactly? It's hard to know what the right solution to the problem is if we don't consider the attack vector that caused it. If we don't discuss the attack vector, we can't be sure the solution will actually solve the problem. It isn't helpful to discuss hypotheticals that may or may not happen, we need to do the threat modelling analysis.
On the opposite end of the spectrum, your example of "*Or if you build a SPA and one of the dependencies contains malicious code*" is completely flawed though. Because, again, how did the dependency contain malicious code? But now this isn't a problem that is limited just to SPAs. Which means we need a solution that protects not just SPAs. If we assume that a library can contain malicious code, when are the dependencies for the browser any different from dependencies for a credentialed client? In my perspective, they aren't. Whichever means caused the dependency to include malicious code for a browser environment, would also include vulnerabilities for all other clients, in a way that no solutions exist. It isn't useful, helpful, or relevant to discuss vulnerabilities in libraries, because "if vulnerabilities in libraries can exist, then they for sure exist for server-side environments" making any solution that does not address server-side environments worthless.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
