Renderiza los datos no confiables como texto, nunca como marcado: deja que el framework los escape y evita innerHTML, dangerouslySetInnerHTML y v-html. Si tienes que aceptar HTML, sanea en el servidor o con un sanitizador mantenido antes de que toque el DOM. Añade una Content Security Policy con nonces para eliminar el script en línea como opción, valida las URL para que ningún esquema javascript acabe en un href, y mantén los tokens fuera de cualquier almacenamiento que un script pueda leer.
Por qué lo preguntan los entrevistadores
Los frameworks escapan por defecto, así que los entrevistadores quieren saber si entiendes los agujeros que quedan: inyección de HTML crudo, sumideros de atributos y de URL, y scripts de terceros. La respuesta muestra si piensas en términos de orígenes y sumideros o solo te acuerdas de escapar. Mencionar CSP y trusted types indica que has entregado defensa en profundidad en vez de asumir que el framework se ocupa de todo.
Cómo estructurar tu respuesta
- Empieza por el valor por defecto: escapar renderizando como texto.
- Nombra los sumideros concretos que se saltan el framework.
- Cubre la inyección en URL y atributos, no solo en el contenido del elemento.
- Añade las defensas por capas: CSP, sanitizador, almacenamiento de tokens.
Ejemplo de respuesta
La base es que todo lo no confiable se renderiza como texto, cosa que el framework hace por mí. Así que el trabajo real es auditar los sitios que se salen de eso. Cualquier innerHTML, cualquier dangerouslySetInnerHTML, cualquier plantilla que escriba marcado crudo, más los sumideros que la gente olvida: un href construido con entrada de usuario puede llevar un esquema javascript, y un atributo style o srcdoc es igual de peligroso. Si una funcionalidad necesita de verdad texto enriquecido, por ejemplo descripciones escritas por usuarios, saneo con una librería mantenida y una lista de permitidos en vez de intentar filtrar etiquetas yo mismo, y lo hago lo más cerca posible del almacenamiento. Encima de eso quiero una Content Security Policy con un nonce para que el script en línea simplemente no se ejecute, lo que convierte la mayoría de los bugs residuales en un mensaje bloqueado en consola y no en una brecha. Y mantengo los tokens de sesión en cookies HttpOnly, porque si un payload aterriza, el radio de la explosión no debería incluir la sesión del usuario.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Dónde no te ayuda una Content Security Policy?
- ¿Cómo renderizarías de forma segura texto enriquecido enviado por usuarios?
- ¿Qué es el XSS basado en DOM y por qué se les escapa a los filtros del servidor?
Más preguntas para Desarrollador frontend
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas