Creo que este mecanismo tendría un valor real solo en un conjunto específico de circunstancias.
En el caso general, de una aplicación web normal, sería mejor que corrijas el código para que sea seguro para XSS, como escribió @SteveS.
Sin embargo, hay algunos escenarios donde esto no es fácilmente posible, y estos escenarios están creciendo en popularidad. Me refiero al "contenido generado por el usuario", donde debe permitir que los usuarios ingresen (casi) cualquier información, incluido el contenido HTML arbitrario: blogs, sitios de redes sociales, CMS, etc. ...
Ahora, la parte de seguridad de mi parte se está encogiendo, y de inmediato quiero saltar y gritar: "No, no necesitas para hacer eso, ¡encuentra una mejor manera! ". Pero, por supuesto, ese no es realmente el punto ...
Y sí, hay formas indirectas de evitar esa situación, ya que los usuarios ingresan un código HTML arbitrario, ya sea con la inclusión de ciertas etiquetas en la lista blanca o mediante un sistema de marcado alternativo (como Markdown utilizado aquí), pero son una especie de confusión, limitando su funcionalidad y no es trivial para algunos usuarios finales.
En pocas palabras, habrá algunas aplicaciones web que aceptarán HTML arbitrario , por cualquier razón que la empresa considere necesaria, y puede ser contraproducente gritar sobre cómo Es inseguro, porque eso no va a funcionar.
En estos casos, la Política de seguridad de contenido puede agregar un gran valor y mitigar la función XSS en gran medida.