Previously, Angular would warn users when simply re-encoding text
outside of the ASCII range. While harmless, the log spam was annoying.
With this change, Angular specifically tracks whether anything was
stripped during sanitization, and only reports a warning if so.
Fixes#10206.
Resource URLs are strictly "more" trustworthy than plain URLs, so trusting them maintains the same level of security while avoiding to break people when we downgrade a resource URL context to a plain URL context.
Allow more elements and attributes from the HTML5 spec which were stripped by the htmlSanitizer.
fixes#9438
feat(security): allow audio data URLs in urlSanitizer
test(security) : add test for valid audio data URL
feat(security): allow and sanitize srcset attributes
test(security): test for srcset sanitization
Mostly, removing things that were never intended to be exported publicy.
BREAKING CHANGE:
The following are no longer publicly exported APIs. They were intended as internal
utilities and you should use your own util:
```
browserDetection,
dispatchEvent,
el,
normalizeCSS,
stringifyElement,
expect (and custom matchers for Jasmine)
```
Allows sanitized URLs for CSS properties. These can be abused for information
leakage, but only if the CSS rules are already set up to allow for it. That is,
an attacker cannot cause information leakage without controlling the style rules
present, or a very particular setup.
Fixes#8514.
This is based on Angular 1's implementation, parsing an HTML document
into an inert DOM Document implementation, and then serializing only
specifically whitelisted elements.
It currently does not support SVG sanitization, all SVG elements are
rejected.
If available, the sanitizer uses the `<template>` HTML element as an
inert container.
Sanitization works client and server-side.
Reviewers: rjamet, tbosch , molnarg , koto
Differential Revision: https://reviews.angular.io/D108
Martin Probst
Joao Dias
Igor Minar
Cyrille Tuzi
Julie Ralph
Wojciech Kwiatek
ScottSWu
Alex Eagle