"How certain are you that that 3rd party does nothing malicious?"
I'm not very certain. But you're missing the point. If the library is tainted, what can it do? Much, much worse than the worst case scenario here. That's the point. It's like duct tape to fix the titanic. It's like humans in a Marvel movie. Useless.
Just like Xavier, a compromised lib can mind-control the poop out of your app and wreak havoc for your users, and there's nothing you can do about it. XSS is a security rabbit hole.
When you understand what a tainted lib can do, you realize how trivial this article's point is. That is my only point.
Part of the problem with the proposed solution in this article is that cookies are tied to a specific domain. That makes it much harder and clunky to use third party security services like Auth0. Also, scalability does become a MUCH harder issue with server-side sessions; I don't care what this article says.
Best idea to overcome your tainted paranoia is to use script's integrity attribute, eg:
"How certain are you that that 3rd party does nothing malicious?"
I'm not very certain. But you're missing the point. If the library is tainted, what can it do? Much, much worse than the worst case scenario here. That's the point. It's like duct tape to fix the titanic. It's like humans in a Marvel movie. Useless.
Just like Xavier, a compromised lib can mind-control the poop out of your app and wreak havoc for your users, and there's nothing you can do about it. XSS is a security rabbit hole.
When you understand what a tainted lib can do, you realize how trivial this article's point is. That is my only point.
Part of the problem with the proposed solution in this article is that cookies are tied to a specific domain. That makes it much harder and clunky to use third party security services like Auth0. Also, scalability does become a MUCH harder issue with server-side sessions; I don't care what this article says.
Best idea to overcome your tainted paranoia is to use script's
integrityattribute, eg: