HTML
Seguridad y políticas de recursos
Cómo HTML participa en la seguridad al cargar recursos mediante CSP, SRI, CORS, referrer policy, sandbox, permisos y atributos de aislamiento.
- Última actualización
- Actualizada
- Nivel
- Aplicación
HTML
Cómo HTML participa en la seguridad al cargar recursos mediante CSP, SRI, CORS, referrer policy, sandbox, permisos y atributos de aislamiento.
Peligroso:
<div>ENTRADA_DEL_USUARIO</div>si una plantilla concatena el valor sin encoding.
La codificación depende del destino:
No existe un escape universal.
Para texto:
element.textContent = userInput;No:
element.innerHTML = userInput;Cuando necesitas HTML de usuarios, utiliza una sanitización mantenida y una política clara de elementos/atributos permitidos.
Header conceptual:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'Puede limitar:
Es defensa en profundidad, no sustituto de prevenir inyección.
<script nonce="valor-aleatorio-por-respuesta">
...
</script>El nonce debe:
Un nonce fijo publicado en el HTML no protege.
CSP puede autorizar un script inline mediante hash de su contenido exacto.
Cambiar espacios o código cambia el hash. Aporta para bloques estáticos pequeños, no para contenido generado arbitrariamente.
<meta
http-equiv="Content-Security-Policy"
content="default-src 'self'"
>Tiene limitaciones, se aplica después de encontrar la etiqueta y no soporta todas las directivas. Prefiere headers HTTP.
Una CSP puede exigir valores confiables para sinks de inyección DOM.
No convierte automáticamente HTML inseguro en seguro; obliga a centralizar políticas de creación y reduce asignaciones accidentales.
<script
src="https://cdn.example.com/library.js"
integrity="sha384-..."
crossorigin="anonymous"
></script>Verifica que el recurso descargado tenga los bytes esperados.
Aporta cuando cargas una versión inmutable de un tercero. No funciona bien si la URL cambia contenido sin versionado; el hash dejará de coincidir.
<link
rel="stylesheet"
href="https://cdn.example.com/styles.css"
crossorigin="anonymous"
>Controla el modo de credenciales/CORS para recursos compatibles.
anonymous: sin credenciales cross-origin.use-credentials: incluye credenciales cuando la política lo permite.El servidor debe responder con headers correctos.
<a href="https://external.example" referrerpolicy="no-referrer">Puede limitar qué parte de la URL actual se comparte.
También se configura mediante header o meta para todo el documento.
Header conceptual:
Permissions-Policy: camera=(), microphone=(), geolocation=(self)Limita APIs disponibles por origen y frames.
En iframe:
<iframe
src="https://video.example"
allow="fullscreen; picture-in-picture"
title="Video"
></iframe>allow delega capacidades dentro de la política general; no concede más de lo permitido por headers, usuario y navegador.
<iframe sandbox="allow-scripts">...</iframe>Restringe contenido embebido. Habilita solo tokens necesarios y revisa combinaciones peligrosas.
Header CSP:
Content-Security-Policy: frame-ancestors 'none'Impide que la página sea embebida por otros origins, mitigando clickjacking.
No puede configurarse mediante meta CSP con el mismo efecto temprano/confiable.
Content-Security-Policy: base-uri 'self'Limita qué URL puede usar base, reduciendo daños si un atacante inyecta esa etiqueta.
Content-Security-Policy: form-action 'self'Limita destinos permitidos para forms. Complementa la validación de action y evita exfiltración mediante formularios inyectados.
Una página HTTPS no debe cargar recursos activos por HTTP:
<script src="http://example.com/app.js"></script>Puede bloquearse o degradar seguridad. Utiliza HTTPS para todos los recursos.
<a
href="https://external.example"
target="_blank"
rel="noopener noreferrer"
>Reduce acceso al opener y referrer. Decide si necesitas ambos tokens según política.
No permitas cualquier scheme en valores generados:
javascript:
data:
file:
https:Para enlaces externos controlados, valida URL, protocol y, si aplica, hostname.
download sugiere descarga, pero el servidor debe enviar headers correctos, nombres seguros y tipos apropiados.
Evita servir archivos subidos por usuarios como HTML ejecutable bajo el mismo origen principal.
Cada script, iframe, font o analytics puede:
Carga el mínimo, fija versiones, revisa políticas y ofrece consentimiento cuando corresponda.
Características como credentialless en iframes o modos privados de proveedores pueden reducir credenciales/almacenamiento en escenarios compatibles. Verifica soporte y no confíes en nombres comerciales sin inspeccionar tráfico.
<script
type="module"
src="https://cdn.example.com/app.v3.js"
integrity="sha384-..."
crossorigin="anonymous"
referrerpolicy="no-referrer"
></script>Debe acompañarse con una CSP, versión inmutable y servidor CORS compatible.
¿Por qué una CSP fuerte no vuelve seguro innerHTML = userInput?
Porque la inyección sigue alterando el DOM y puede habilitar ataques dentro de lo permitido por la política; CSP solo reduce ciertas vías de ejecución y es defensa adicional.
Rendimiento, carga y validación reúne decisiones HTML que afectan velocidad, estabilidad y calidad.