This repository has been archived by the owner on Sep 5, 2024. It is now read-only.
fix(all): fix Trusted Types violations during initialization #12128
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, when Angular Material is loaded in an application that has Trusted Types enforced, two violations occur. Both violations are caused when a plain string is passed to angular.element since there is no guarantee that the string was not derived from user input, which could cause XSS. It should be noted that, in this case, neither call to angular.element represents a security vulnerability, but this blocks Trusted Types adoption in applications that load Angular Material. To fix the violations, refactor the calls to angular.element to use safe DOM operations instead. This change does not alter any functionality and is fully backwards compatible.
google-cla
bot
added
the
cla: yes
Splaktar
added
g3: pr
jelbourn
pushed a commit
that referenced
this pull request
Oct 28, 2021
Currently, when Angular Material is loaded in an application that has Trusted Types enforced, two violations occur. Both violations are caused when a plain string is passed to angular.element since there is no guarantee that the string was not derived from user input, which could cause XSS. It should be noted that, in this case, neither call to angular.element represents a security vulnerability, but this blocks Trusted Types adoption in applications that load Angular Material. To fix the violations, refactor the calls to angular.element to use safe DOM operations instead. This change does not alter any functionality and is fully backwards compatible. (cherry picked from commit 4e354a6)
superheri
pushed a commit
to superheri/material
that referenced
this pull request
Nov 30, 2021
…#12128) Currently, when Angular Material is loaded in an application that has Trusted Types enforced, two violations occur. Both violations are caused when a plain string is passed to angular.element since there is no guarantee that the string was not derived from user input, which could cause XSS. It should be noted that, in this case, neither call to angular.element represents a security vulnerability, but this blocks Trusted Types adoption in applications that load Angular Material. To fix the violations, refactor the calls to angular.element to use safe DOM operations instead. This change does not alter any functionality and is fully backwards compatible.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
AngularJS Material is in LTS mode
We are no longer accepting changes that are not critical bug fixes into this project.
See Long Term Support for more detail.
PR Checklist
Please check your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Currently, when Angular Material is loaded in an application that has
Trusted Types enforced, two violations occur. Both violations are caused
when a plain string is passed to angular.element since there is no
guarantee that the string was not derived from user input, which could
cause XSS. It should be noted that, in this case, neither call to
angular.element represents a security vulnerability, but this blocks
Trusted Types adoption in applications that load Angular Material.
What is the new behavior?
To fix the violations, refactor the calls to angular.element to use safe
DOM operations instead.
Does this PR introduce a breaking change?
Other information
@jelbourn