The examples I have listed are well known attack vectors, as they have often lead to breaches. Who cares how a third-party library you are importing into your pages became compromised, it is completely out of our control anyway. The only thing that matters is the potential impact and what it means for the security of the application we’re trying to protect. And yes, my list was not exhaustive to cover all bases, as you seem to demand. Malicious dependencies are a problem everywhere, also on the backend, but are often less visible or underestimated in frontends (ever tried to keep a 2-year old frontend free of vulnerable dependencies?).
Anyway, I only jumped in to counter the misinformation on CSP, so I’m giving this thread a rest for now. Philippe > On 9 Nov 2025, at 18:04, Warren Parad <[email protected]> wrote: > > 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]
