La prevención XSS tiene que ver con el contexto. Necesita diferentes estrategias dependiendo del contexto en el que se insertarán los datos no confiables de los que se está escapando.
Aunque creo que su método estaría bien dentro de los elementos HTML y en los atributos HTML entre comillas dobles, tendría problemas en los siguientes contextos:
- En los atributos HTML con comillas simples o sin comillas, serás pwned.
- en, por ejemplo, un atributo
href
, usted sería pwned con p. ej. una URL javascript:
o vbscript:
.
- En los literales de cadena de JavaScript que utilizan comillas simples, se le prometerá.
- En los literales de cadena de JavaScript que utilizan comillas dobles, un atacante podría detener la ejecución del script insertando una nueva línea y, por lo tanto, provocar un error de sintaxis. Esto podría tener consecuencias inesperadas y adversas en algunas circunstancias.
- Y luego está el CSS, que tiene su propio conjunto de reglas diferentes ...
Para obtener una guía detallada sobre cómo hacer esto correctamente, recomiendo encarecidamente la hoja de trucos de prevención OWASP XSS . Creo que las principales lecciones para llevar a casa de todo esto es: XSS es complicado. No confíe en su propia solución elaborada en casa para detenerla. Use una biblioteca bien probada en su lugar.
(Y Alexander O'Mara tiene toda la razón en su comentario. Si está en el navegador , solo ve con textContent
.)