> There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it.
I'm much more likely to rip out the one function I need out of a framework or library and put it in my code, with a comment "// stolen from <source>". I've spent lots of time untangling the crux of someone's implementation away from the problematic abstractions they built up around it to make it universally adaptable.
Usually the security issues come from the wrapper code that tries to hammer the square peg of an algorithm into the round hole of the abstraction they provide. Dropping the wrapper code is the safest thing you can do.
I used to be a web app security tester. I loved it when I got an app that didn't use a framework for development because I knew I'd get some security issues for sure.
In the context of web applications, frameworks mean that your devs don't have to be experts in SQL Injection, XSS, SSRF, Session management etc etc etc.
My experience over several hundred tests was that without a framework there weren't many apps that could get that right first time. If they were lucky the pentesters found the issues, if they were unlucky, it was attackers.
A library could work here too, to turn off the footguns and provide safe tooling. No need for the library to also intercept all of the DOM callbacks for you as well.
I'm much more likely to rip out the one function I need out of a framework or library and put it in my code, with a comment "// stolen from <source>". I've spent lots of time untangling the crux of someone's implementation away from the problematic abstractions they built up around it to make it universally adaptable.