We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security scanner bearer/bearer reports the following issue:
bearer/bearer
CRITICAL: Dangerous dynamic HTML insert detected. [CWE-79] https://docs.bearer.com/reference/rules/javascript_lang_dangerous_insert_html File: autocomplete_controller.js:232 232 this.resultsTarget.innerHTML = html
originating out of the replaceResults(html) function called by fetchResults(query).
replaceResults(html)
fetchResults(query)
Looking at github/auto-complete-element it appears that it's using a similar fetch call, but with a recommendation to use DOMPurify and a CSP Trusted Types policy to sanitize the HTML returned by the fetch response before inserting it into the DOM sink with .innerHTML (https://github.com/github/auto-complete-element?tab=readme-ov-file#csp-trusted-types / https://web.dev/articles/trusted-types#use_a_library)
github/auto-complete-element
fetch
DOMPurify
.innerHTML
I'm wondering whether the current implementation of this library is vulnerable to an XSS?
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Security scanner
bearer/bearer
reports the following issue:originating out of the
replaceResults(html)
function called byfetchResults(query)
.Looking at
github/auto-complete-element
it appears that it's using a similarfetch
call, but with a recommendation to useDOMPurify
and a CSP Trusted Types policy to sanitize the HTML returned by thefetch
response before inserting it into the DOM sink with.innerHTML
(https://github.com/github/auto-complete-element?tab=readme-ov-file#csp-trusted-types / https://web.dev/articles/trusted-types#use_a_library)I'm wondering whether the current implementation of this library is vulnerable to an XSS?
The text was updated successfully, but these errors were encountered: