Jesse Niininen

It'd still work if `req.body` is `any` and not `unknown`. If it's unknown you can just cast it to `any`. It'd be breaking change for sure, but the fix would...

See: https://github.com/Dogfalo/materialize/issues/6286

> These are no real XSS. I'm not sure why you're still going with this narrative. Autocomplete vulnerability is almost textbook example of XSS, see [DOM based XSS](https://www.owasp.org/index.php/DOM_Based_XSS) for reference....

Dogfalo already confirmed autocomplete rendering html is not a feature, so no point in continuing the argument over this. > That makes me sad, sorry. I'm not going to waste...

So you're really going the route that Snyk doesn't know what a vulnerability and xss is? They've literally made a business of knowing these things. > Can you send me...

Text field is not one of the vulnerable components. If you render user input as html on server side, it's obviously your fault and doesn't really have much to do...

> let's say i'm getting the content for data json object from my server via ajax, then i wouldn't need to worry about the XSS injection scenario which you've simulated...

Now you're on right tracks. innerText is indeed safe, you won't be able to execute any scripts using it, but autocomplete uses innerHTML equivalent. If you do ``` content.innerHTML=''; ```...

Good to hear @Divine1. About your solution to fix it, I don't think it's enough, as the element is then passed to _highlight function which will rewrite the element innerHTML....

> Only via iframe XSS attack is possible for tooltip and toast ? No, anything works there. It should be quite obvious though, since you're passing a field named `html`....