Planteamiento y contexto
Un producto SaaS está agregando texto enriquecido creado por usuarios a comentarios, una base de conocimiento y plantillas. El equipo desea utilizar la API HTML Sanitizer nativa del navegador para reducir las reglas de filtrado personalizadas, pero la API no está disponible en algunos navegadores principales. Decide si adoptarla y explica las ventajas y desventajas en materia de seguridad, experiencia, compatibilidad y operación.
Lo que evalúa el entrevistador
- Si defines primero el modelo de amenazas, el contenido permitido y el límite de confianza del servidor.
- Si distingues
setHTML(), configuraciones personalizadas de Sanitizer,setHTMLUnsafe()y Trusted Types. - Si se cuantifican la cobertura de navegadores, la implementación de contingencia (fallback), la consistencia del contenido y el costo de migración.
- Si métricas por etapas validan el riesgo de XSS, el éxito de edición, el rendimiento y la preparación para reversiones.
Preguntas de clarificación para hacer
Confirma si el texto enriquecido necesita enlaces, imágenes, tablas, incrustaciones (embeds), estilos o atributos personalizados; si el contenido se renderiza del lado del servidor, se exporta a correo electrónico, se indexa para búsquedas o se reutiliza en otros clientes. Confirma los navegadores compatibles, los sanitizadores existentes, las necesidades de cumplimiento, la superficie de ataque y la degradación aceptable de funciones.
Respuesta de 30 segundos
Utilizaría una alternativa progresiva basada en capacidades, con prioridad nativa y validada en el servidor, en lugar de reemplazar el sanitizador existente de golpe. setHTML() nativo sigue una ruta de sanitización segura, pero la cobertura es limitada, por lo que los navegadores no compatibles utilizan una política equivalente auditada. Comienza con una superficie de baja complejidad como los comentarios y mide el bloqueo de cargas útiles peligrosas, la fidelidad del contenido, el éxito de edición, la latencia y la distribución de navegadores. El servidor sigue sanitizando y codificando en los límites de salida; Trusted Types añade una restricción en torno a los sumideros (sinks) de inyección.
Análisis detallado paso a paso
1. Definir el valor de usuario y el modelo de amenazas
El valor para el usuario es un contenido formateado y confiable; el riesgo principal es enviar HTML no confiable al DOM o a otro sumidero de renderizado. Define los elementos, atributos, esquemas de URL y fuentes de medios permitidos antes de decidir qué capacidades justifican el costo de mantenimiento.
2. Separar las capacidades de la API nativa
Element.setHTML() y Document.parseHTML() utilizan valores predeterminados de sanitización seguros; una configuración personalizada puede restringir la lista de permitidos. setHTMLUnsafe() es para casos que necesitan una estructura especial, pero requiere una configuración y revisión estrictas. La especificación exige métodos seguros para eliminar el marcado con capacidad de ejecutar scripts, por lo que la API no es una autorización para HTML arbitrario.
3. Evaluar la cobertura y el mecanismo de reserva (fallback)
MDN etiqueta la API HTML Sanitizer como de disponibilidad limitada. Detecta mediante características la ruta nativa y elige una ruta de servidor o de biblioteca auditada cuando no sea compatible. Comparte listas de permitidos, accesorios de prueba (test fixtures) y registros de versiones en ambas rutas. Un mecanismo de reserva debe descartar capacidades de alto riesgo en lugar de relajar la política para mantener la paridad visual.
4. Diseñar un contrato de contenido entre clientes
Almacena la entrada original y una representación segura normalizada, definiendo qué representación sirve para edición, vista previa, correo electrónico, búsqueda y exportación. Revalida en cada límite de salida del servidor. La sanitización del lado del cliente reduce el riesgo de inyección en el DOM; no reemplaza la autorización, el almacenamiento o la política de renderizado del servidor.
5. Diseñar un despliegue gradual y métricas
Habilita un tipo de contenido para una cohorte pequeña de inquilinos y compara los hallazgos nativos y del mecanismo de reserva. Realiza un seguimiento del bloqueo de cargas útiles peligrosas, apelaciones por eliminaciones no deseadas, éxito en el envío de ediciones, latencia de entrada y primer renderizado, cobertura de navegadores, consistencia de versiones de políticas y eventos de seguridad.
6. Gestionar Trusted Types y operaciones
Habilita el reporte o la aplicación de Trusted Types para sumideros de alto riesgo, exigiendo que las funciones de política devuelvan tipos validados. Establece la aprobación de cambios de reglas, regresión de fixtures maliciosos, reprocesamiento de contenido y reversión de emergencia. No permitas que una actualización del navegador cambie silenciosamente la política de seguridad.
Respuesta de muestra de alta calidad
Colocaría la capacidad de contenido, el modelo de amenazas y el entorno de ejecución en tres tablas de decisión. La API HTML Sanitizer es útil para la limpieza estructurada del lado del cliente antes de que el HTML no confiable ingrese al DOM; setHTML() tiene valores predeterminados seguros y la especificación WHATWG reduce la posibilidad de que se conserve marcado con capacidad de ejecutar scripts, pero MDN aún marca la cobertura como limitada. El plan de producto es dar prioridad a lo nativo con un mecanismo de reserva en biblioteca madura o política de servidor, compartiendo elementos, atributos, esquemas y fixtures permitidos. El servidor almacena representaciones originales y seguras y valida por separado para páginas, correo electrónico, búsqueda y exportación; la limpieza del cliente no proporciona autorización ni protección completa contra XSS. Despliega primero en comentarios y mide el bloqueo, la fidelidad, el éxito del envío, el rendimiento, la distribución de navegadores y los eventos de seguridad. Utiliza setHTMLUnsafe() solo ante un requisito de estructura justificado con configuración estricta, Trusted Types y revisión. Reproduce fixtures maliciosos históricos después de las actualizaciones de políticas y revierte de inmediato ante cualquier regresión.
Errores comunes
- Asumir que una API nativa del navegador elimina la necesidad de sanitización del lado del servidor.
- Probar solo la demostración e ignorar los navegadores no compatibles y la consistencia del mecanismo de reserva.
- Relajar la configuración de
setHTMLUnsafe()para preservar incrustaciones arbitrarias. - Reemplazar las métricas de fidelidad, eliminación no deseada y seguridad con un solo número de éxito de filtrado.
- Tratar a Trusted Types como un sanitizador, o a un sanitizador como autorización.
Preguntas de seguimiento y respuestas
¿Por qué no cambiar todas las superficies a la API nativa de inmediato?
La cobertura, la capacidad de contenido y la migración de datos heredados siguen siendo inciertas. Un despliegue reversible con mecanismo de reserva valida primero las distribuciones reales de navegadores y contenido.
¿Qué ocurre si las políticas nativas y del servidor difieren?
Comparte listas de permitidos versionadas y fixtures maliciosos, con el servidor como límite final. Registra versiones de políticas y muestras cuando el cliente encuentre una diferencia; nunca relajes la regla silenciosamente.
¿Cuándo vale la pena activar la aplicación de Trusted Types?
Una vez que se hayan inventariado los sumideros principales, se hayan migrado las funciones de política y los componentes de terceros, y el modo de solo reporte muestre pocos falsos positivos, habilita la aplicación por etapas.