The official documentation at angular.io does a genuinely good job of steering you toward safe defaults, but a run of 2025 CVEs proves that "the framework handles it" is a claim with edges. Angular's built-in contextual escaping stops most cross-site scripting before it starts, its HTTP client ships CSRF protection, and its server-side rendering is fast. All three of those areas produced disclosed vulnerabilities in late 2025. If you build on Angular, the reference docs are your starting point, not your finish line.
I maintain a couple of Angular front ends that talk to sensitive back ends, so I read every advisory the team publishes. Here is what actually mattered this year and what to do about it.
Angular's Security Model, Briefly
Angular treats all values bound into templates as untrusted by default and escapes them for the context they land in. Interpolation with {{ }} escapes HTML. Property bindings sanitize URLs and styles. If you want to bypass that, you have to reach for bypassSecurityTrustHtml and friends, which is deliberately awkward so you notice you are doing it.
That model is sound. The angular.io security guide is explicit that the framework's job is to sanitize, and your job is to not hand it pre-trusted strings built from user input. Most XSS I have seen in Angular apps comes from someone calling a bypass method on a string that turned out to be attacker-controlled, or from rendering server HTML with [innerHTML] without thinking about where it came from.
CVE-2025-66412: When the Sanitizer Has a Blind Spot
The reassuring story above cracked a little in 2025. CVE-2025-66412 is a stored XSS in Angular's sanitizer: attacker-controlled content in certain SVG animation and MathML attributes could bypass the built-in protections and execute in the victim's browser. The point of a framework sanitizer is that you do not have to reason about SVG animation attributes yourself, so a gap there is exactly the kind of thing you cannot catch by reading your own code.
The lesson is not "distrust the sanitizer." It is that a sanitizer is code, code has bugs, and the mitigation is staying current. This CVE was fixed in the patched releases; if you pinned an old minor and stopped upgrading, you were exposed to a hole you had no way to find yourself.
CVE-2025-66035: XSRF Tokens Leaking Cross-Origin
The Angular HTTP client automatically attaches the XSRF token to same-origin requests. CVE-2025-66035 showed that a protocol-relative URL, one starting with //example.com, was incorrectly treated as same-origin, so the client attached the X-XSRF-TOKEN header and shipped the token to an attacker-controlled host. That defeats the CSRF protection entirely, because the whole scheme depends on the token being secret to the origin.
If any part of your code builds request URLs from configuration or user input, this is a concrete reason to audit how those URLs are formed. Protocol-relative URLs are a footgun in more places than Angular, and a request URL that can start with // is a request URL an attacker may be able to redirect.
CVE-2025-59052: SSR Data Leaking Between Users
Server-side rendering is where Angular gets its fast first paint, and it is also where 2025's most unsettling bug lived. CVE-2025-59052 was a race condition in the SSR pipeline: Angular reused a shared injector across concurrent requests, so under load, request-scoped data from one user could surface in another user's rendered response. Data from User A appearing in User B's page is about as bad as a leak gets, and it needed no attacker at all, only traffic.
If you run Angular SSR (Angular Universal or the newer built-in SSR), this alone justifies an upgrade. Cross-request leakage does not show up in functional testing because it only manifests under concurrency, which is exactly why it sat undetected.
What To Actually Do
The patched versions the team shipped were v19.2.17, v20.3.15, and v21.0.2, and the advisories listed no fix for v18 and older, which means those branches need a major upgrade rather than a patch bump.
Concrete steps:
- Upgrade to a patched minor now if you are on v19, v20, or v21, and plan a migration off v18 or earlier.
- Wire
npm auditor an equivalent into CI so a newly disclosed Angular CVE fails a build instead of waiting for someone to read a newsletter. Tracking transitive advisories is a job for tooling; an SCA workflow can flag a vulnerable@angular/*package version across every repo at once. - Audit every
bypassSecurityTrust*call and every[innerHTML]binding. These are where your own code, not the framework, introduces XSS. - Grep for protocol-relative URL construction in HTTP calls, especially anywhere a base URL comes from config.
For the deeper background on why "the framework sanitizes it" is a necessary but insufficient defense, the angular.io security guide itself is the right primary source, and it is refreshingly honest about the boundary between what Angular protects and what it cannot.
Dependencies Around Angular Matter Too
Angular apps are npm apps. The framework packages are one input; your @angular/material, your state library, your build plugins, and their transitive dependencies are the rest. A clean Angular version does not save you from a compromised or vulnerable dependency three levels down, which is the ordinary supply-chain reality of any JavaScript project. Keeping a lockfile, reviewing what enters it, and scanning it regularly does more for real-world safety than any single framework upgrade.
FAQ
Is angular.io the official Angular documentation?
Yes. angular.io is the canonical documentation and security-guide home for the Angular framework, maintained by the Angular team. It is the authoritative place to read about the sanitization model and to find links to published security advisories.
Which Angular versions are affected by the 2025 CVEs?
The disclosed 2025 issues affected a range of versions, with fixes shipped in v19.2.17, v20.3.15, and v21.0.2. Versions 18 and older were listed without patches in the relevant advisory, so those branches require upgrading to a supported major.
Does Angular's built-in sanitizer make my app XSS-proof?
No. It stops the common cases and it is a strong default, but CVE-2025-66412 showed the sanitizer itself can have gaps, and calling bypassSecurityTrustHtml on user-controlled input reintroduces XSS regardless. Stay patched and audit your bypass calls.
How do I keep up with Angular security advisories?
Watch the Angular GitHub security advisories, subscribe to the release notes, and put dependency scanning in CI so a newly published CVE against an @angular/* package fails a build automatically rather than depending on someone noticing.