Django, Rails, Spring Security, React, Angular, ASP.NET Core and Laravel now escape page output, build database queries safely and, in several cases, check for cross-site request forgery by default. Some of this is older than people assume: Django's CSRF check and Rails' output escaping both date to 2010. I wanted to know whether it shows up in the vulnerability record.
Where researchers have looked closely at particular applications, these defences do go with fewer of the flaws they target. In a small study of nine applications, only the two with framework CSRF support were free of CSRF flaws, and Google reports that its own stricter internal frameworks have nearly removed cross-site scripting and SQL injection, though those figures are unaudited. Across published software as a whole it's murkier. Among more than 33,000 GitHub-reviewed advisories, the share that are cross-site scripting, SQL injection or CSRF falls slightly between 2015 and 2025 under one way of dating advisories and doesn't fall at all under another. SQL injection doesn't fall under either, and all three still rank first, second and third in MITRE's 2025 list of the most dangerous software weaknesses.
The frameworks are honest about what they leave to you. The main gap is who may see or change what, along with file uploads, redirects, login throttling and raw database queries. Access-control problems are growing as a share of advisories and sit first in the OWASP Top 10, which is exactly the class no default can cover.
So the defaults remove the easy route to a few flaw types rather than removing the flaw types, and they leave several important classes untouched. That isn't an argument that they're worthless. It's that the win is narrower than the framework-era story suggests, and the weaknesses that remain are the ones nobody can automate away.