🚨 [security] Update all of angular 12.1.1 → 21.0.1 (major)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ @​angular/animations (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/common (12.1.1 → 21.0.1) · Repo · Changelog

Security Advisories 🚨

🚨 Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client

The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain.

Angular's HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header.

Impact

The token leakage completely bypasses Angular's built-in CSRF protection, allowing an attacker to capture the user's valid XSRF token. Once the token is obtained, the attacker can perform arbitrary Cross-Site Request Forgery (CSRF) attacks against the victim user's session.

Attack Preconditions

1. The victim's Angular application must have XSRF protection enabled.
2. The attacker must be able to make the application send a state-changing HTTP request (e.g., POST) to a protocol-relative URL (e.g., //attacker.com) that they control.

Patches

• 19.2.16
• 20.3.14
• 21.0.1

Workarounds

Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.

🚨 Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client

The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain.

Angular's HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header.

Impact

The token leakage completely bypasses Angular's built-in CSRF protection, allowing an attacker to capture the user's valid XSRF token. Once the token is obtained, the attacker can perform arbitrary Cross-Site Request Forgery (CSRF) attacks against the victim user's session.

Attack Preconditions

1. The victim's Angular application must have XSRF protection enabled.
2. The attacker must be able to make the application send a state-changing HTTP request (e.g., POST) to a protocol-relative URL (e.g., //attacker.com) that they control.

Patches

• 19.2.16
• 20.3.14
• 21.0.1

Workarounds

Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.

🚨 Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angular HTTP Client

The vulnerability is a Credential Leak by App Logic that leads to the unauthorized disclosure of the Cross-Site Request Forgery (XSRF) token to an attacker-controlled domain.

Angular's HttpClient has a built-in XSRF protection mechanism that works by checking if a request URL starts with a protocol (http:// or https://) to determine if it is cross-origin. If the URL starts with protocol-relative URL (//), it is incorrectly treated as a same-origin request, and the XSRF token is automatically added to the X-XSRF-TOKEN header.

Impact

The token leakage completely bypasses Angular's built-in CSRF protection, allowing an attacker to capture the user's valid XSRF token. Once the token is obtained, the attacker can perform arbitrary Cross-Site Request Forgery (CSRF) attacks against the victim user's session.

Attack Preconditions

1. The victim's Angular application must have XSRF protection enabled.
2. The attacker must be able to make the application send a state-changing HTTP request (e.g., POST) to a protocol-relative URL (e.g., //attacker.com) that they control.

Patches

• 19.2.16
• 20.3.14
• 21.0.1

Workarounds

Developers should avoid using protocol-relative URLs (URLs starting with //) in HttpClient requests. All backend communication URLs should be hardcoded as relative paths (starting with a single /) or fully qualified, trusted absolute URLs.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/compiler (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/core (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/forms (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/platform-browser (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/platform-browser-dynamic (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

✳️ @​angular/router (12.1.1 → 21.0.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

---

👉 No CI detected

You don't seem to have any Continuous Integration service set up!

Without a service that will test the Depfu branches and pull requests, we can't inform you if incoming updates actually work with your app. We think that this degrades the service we're trying to provide down to a point where it is more or less meaningless.

This is fine if you just want to give Depfu a quick try. If you want to really let Depfu help you keep your app up-to-date, we recommend setting up a CI system:

* [Circle CI](https://circleci.com), [Semaphore ](https://semaphoreci.com) and [Github Actions](https://docs.github.com/actions) are all excellent options. * If you use something like Jenkins, make sure that you're using the Github integration correctly so that it reports status data back to Github. * If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with `depfu/`.

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)