Puede intentar crear un elemento temporal, establecer el valor de la entrada en la propiedad innerHTML del elemento y verificar el childElementCount del elemento:

 function checkForHTML(text){ var elem = document.createElement('div') elem.innerHTML = text; return !!elem.childElementCount; } button.addEventListener('click', function(){ console.log(checkForHTML(input.value)) })

 <input id="input"> <button id="button">Check</button>

Por favor, no hagas esto. No puede simplemente usar algunos ingeniosos RegExp para verificar la inyección de scripts. Hay muchos vectores de ataque en los que puede engañar a las inyecciones donde RegExp simplemente no puede coincidir bien. Esto implica, por ejemplo, usar codificaciones \u0001 UTF8 o codificaciones de entidades HTML (< se convierte en & lt;, o & # 60; o & # x003C;) (lol en la publicación original incluso funcionó aquí...) que pasará su validación pero se transforma automáticamente para que la ejecución sea posible. He estado escribiendo tales exploits por diversión, así que puedo garantizarles que hay casi tantas formas de explotar tales algoritmos como creatividad en la mente de un hacker/cracker.

La forma correcta de protegerse de tales inyecciones de secuencias de comandos/XSS es, en primer lugar, no confiar en el contenido generado por el usuario. No confíe también en la "lógica de validación". No debe simplemente aceptar código HTML, JS o CSS cuando se genera de alguna manera en el lado del cliente. Nunca. Nunca debe guardar dicho contenido en una base de datos, ni transferirlo por ningún otro medio y renderizarlo nuevamente. El contenido generado por el usuario que está o podría estar en forma de CSS, HTML o JS es malo y debe tratarse como una bomba nuclear.

Cada contenido que el cliente envía al servidor y que se vuelve a procesar en el lado del cliente de alguna manera no debe ser desinfectado, sino que debe procesarse explícitamente a través de (htmlElement).innerText = contenido de usuario (pseudocódigo); Se garantiza que innerText no creará nodos DOM más que TextNodes, que es la única manera de estar seguro de que está seguro. Nunca, jamás, renderice in situ en HTML o CSS. Observación: También puedo hacer código CSS XSS, por ejemplo, usando complementos CSS específicos del proveedor.

Ejemplo: behavior:url(script.htc); -moz-binding: url(script.xml#mycode);

Simplemente nunca use .innerHTML = también. Nunca permita que el código generado por el usuario afecte directamente al DOM, nunca haga < div > render($content) </ div > ni nada por el estilo.

Para el contenido que debe tener estilo, use un DSL. Podría ser un JSON o cualquier otro DSL como Markdown, etc. si necesita uno simple, que divida el contenido de texto de la información de contexto. Luego, mediante el código en el que confía, recorra esa estructura de datos y represente los elementos HTML / DOM y siempre use .innerText o uso garantizado de .innerText para representar el contenido generado por el usuario (React, por ejemplo, está garantizado para usar esa API, excepto que esté explícitamente usando innerHTML o dangerouslySetInnerHTML SetInnerHTML que es solo sabotaje). Tampoco permita que el contenido generado por el usuario establezca atributos de elementos HTML. Puedo XSS eso también.

Ejemplo: < a href="javascript:alert('XSS!')" / >