¿Qué es la seguridad CSS? | Cómo prevenir phishing y clickjacking mediante ataques CSS

La confianza del usuario es visual. Los usuarios solo pueden confiar en lo que ven. Es el navegador quien cumple esta promesa visualmente. Es CSS quien entrega esta promesa visual. CSS es mucho más que dar estilo para que las páginas luzcan bien y tu marca destaque.

CSS entrega la interfaz de usuario: lo que los usuarios pueden ver y lo que no. Si no ves una ventana emergente de advertencia, ¿por qué te preocuparías? Cuando los atacantes controlan lo que se renderiza en los navegadores, controlan la confianza del usuario. Pueden engañarlos inyectando CSS malicioso. Por eso CSS también es una superficie de ataque oculta.

En marzo de 2025, 150.000 sitios web lo aprendieron de la peor manera. Los visitantes que esperaban sitios legítimos encontraron plataformas de juego chinas. ¿Cómo se hizo? Los atacantes inyectaron JavaScript malicioso y usaron superposiciones CSS para reemplazar páginas reales.

Resumen

• Por qué CSS es un riesgo de seguridad: CSS controla lo que los usuarios ven. Si los atacantes encuentran un punto de entrada, pueden superponer una interfaz falsa para llevar a cabo ataques de phishing en múltiples pasos.
• Cómo funcionan los ataques basados en CSS: Primero, los atacantes obtienen una vía de inyección (a menudo mediante XSS o scripts de terceros). Luego, CSS puede usarse para suprimir alertas, reposicionar elementos, reordenar contenido o apilar superposiciones invisibles para clickjacking y phishing.
• Consejos para prevenir el abuso de CSS: Restringe las fuentes de estilos con CSP, protege los activos estáticos con SRI, bloquea la incrustación en iframes y refuerza la protección contra vulnerabilidades XSS. Como alternativa, usa una herramienta de monitoreo continuo como cside para vigilar los cambios en el DOM.

¿Qué es CSS?

HTML, CSS y JavaScript: ¿quién hace qué?

CSS, abreviatura de Cascading Style Sheets, define el aspecto visual de las páginas de tu sitio web. Controla la capa visual: bordes, alineación, colores, fuentes, espaciado, tamaño y muchas otras características de estilo.

Funciona en armonía con HTML, que proporciona la estructura y el contenido de la página, junto con JavaScript, que gestiona el comportamiento y la lógica: maneja clics, muestra mensajes de error, envía o recupera datos de un servidor. Por ejemplo, HTML define <form>, <button> o <input>, CSS elige colores, diseños y fuentes, y JavaScript añade propiedades dinámicas y la validación o API de la solicitud.

Por qué CSS importa para la seguridad web

<compare-table data='{ "head_class": "!font-normal !bg-white", "cols": { "css": { "title": "Capacidades de CSS" }, "browser": { "title": "Comportamiento del navegador" }, "attack": { "title": "Ataque e impacto" } }, "rows": [ { "css": "url() en background-image, @font-face, iconos", "browser": "Solicita recursos externos (fuentes, imágenes, iconos)", "attack": "El atacante modifica hojas de estilo o URLs de recursos" }, { "css": "display: none; visibility: hidden; contenido fuera de pantalla", "browser": "Renderiza lo que es visible u oculto, en pantalla o fuera de ella", "attack": "Interfaz manipulada: advertencias ocultas, banners de consentimiento minimizados, botones desplazados" }, { "css": "Rediseñar botones, formularios, banners", "browser": "Aplica estilos a nodos del DOM creados por HTML/JS", "attack": "El atacante inyecta HTML/JS (XSS, activos comprometidos)" }, { "css": "Superposiciones, capas que se sitúan encima", "browser": "Hace que el contenido inyectado parezca "nativo" si coincide con el CSS existente", "attack": "El CSS existente hace que el DOM malicioso parezca normal y de confianza" } ] }'

He aquí por qué los profesionales de seguridad deben prestar atención: HTML, JavaScript y CSS se ejecutan en el navegador y comparten el mismo origen y los mismos límites de confianza. El Document Object Model (DOM) es clave aquí. Cuando se carga una página, el navegador analiza el HTML en el árbol DOM y el CSS en el CSS Object Model (CSSOM). El resultado es un Render Tree que contiene solo los elementos visibles y con estilo aplicado.

JavaScript está diseñado para leer y manipular el DOM: puede añadir, cambiar, eliminar y ocultar elementos en tiempo de ejecución.

Todo lo que puede cambiar el DOM, como HTML o JavaScript inyectado, puede cambiar la interfaz y lo que se muestra en la pantalla del usuario. Eso crea oportunidades y riesgos.

Por eso la seguridad CSS debe comenzar por prevenir la manipulación del DOM: prevención de XSS, CSP y seguridad de la cadena de suministro.

CSS: del diseño visual a la superficie de ataque

A diferencia de JavaScript, CSS no puede ejecutar código, pero sí puede indicar al navegador que cargue recursos adicionales como fuentes, imágenes o iconos desde servidores externos. Por ejemplo, los valores url() de CSS en background-image o @font-face pueden indicar al navegador que obtenga esos recursos de servidores externos.

Cada hoja de estilo es un canal potencial a través del cual el navegador solicita recursos externos y, por lo tanto, forma parte de la postura general de seguridad del lado del cliente.

Incluso sin ejecutar código, CSS decide qué se muestra y qué permanece oculto con display:none; o visibility:hidden;. También puede reposicionar contenido fuera de la pantalla, de modo que los usuarios ni siquiera vean ciertas opciones o botones. Puede mover y rediseñar botones y formularios, ocultar o minimizar visualmente advertencias y banners de consentimiento, o incluso añadir capas que cambien la forma en que los usuarios interactúan con la página.

Si los atacantes pueden cambiar qué hojas de estilo se cargan o qué imágenes, fuentes o iconos referencian, pueden influir en lo que los usuarios ven.

Así es como CSS se convierte en parte de tu superficie de ataque CSS y de tu superficie de ataque del lado del cliente en general, y por qué debe incluirse en tu gestión y evaluación de riesgos. Tras una vulnerabilidad de inyección, como cross site scripting, los actores maliciosos pueden weaponizar CSS.

Cómo CSS lleva a los usuarios a confiar en ti

Los usuarios confían en lo que ven si la interfaz se comporta como esperan. Si la interfaz les resulta familiar, confían en el proceso.

Eso convierte la jerarquía visual en una preocupación de diseño UX. Pero se convierte en una preocupación de seguridad cuando los atacantes manipulan un diseño de confianza. Por ejemplo, diseñas tu botón "Pagar ahora" para que destaque con mensajes de error claros que sean obvios y legibles, no difíciles de encontrar o fáciles de pasar por alto.

Lo contrario también es cierto. Los diseños deficientes son confusos y llevan a clics erróneos o a acciones irreversibles sin advertencia, lo que reduce la confianza. Un CSS adecuado y un diseño de interfaz reflexivo deben evitar diseños confusos y reducir los clics erróneos. Deben proporcionar retroalimentación inequívoca y dar señales visuales claras sobre lo que está ocurriendo y lo que se espera de los usuarios.

El UX "seguro por diseño" usa CSS para apoyar y ayudar a los clientes a encontrar su camino con confianza en tus aplicaciones. Si los usuarios están confundidos y no entienden qué está pasando ni por qué, tus controles de seguridad no surten efecto.

Los usuarios confían en los patrones y los atacantes lo saben: inyectan algo de CSS, reposicionan un botón de pago, ocultan una advertencia y superponen un formulario de pago falso.

Cómo se usa CSS en ataques de clickjacking

Además, los márgenes negativos pueden empujar elementos fuera de la pantalla. Una advertencia de seguridad puede desplazarse fuera del área visible usando .security-warning { margin-top: -9999px; }.

Otros trucos para manipular lo que los usuarios ven:

• display: none elimina contenido
• visibility: hidden oculta contenido y preserva su espacio
• overflow: hidden recorta contenido que puede contener advertencias
• overflow: visible extiende el contenido fuera de su contenedor superponiéndose a otros elementos

Para flujos críticos como inicio de sesión, consentimiento o pago, es necesario verificar el tamaño de los elementos en el DOM y si hay algo apilado encima o empujado fuera de la vista.

Puntos de entrada de ataques CSS: XSS, CDNs, cadena de suministro y widgets

En la mayoría de los casos, los atacantes necesitan primero un punto de entrada. Así es como introducen CSS malicioso en tu página:

• Vulnerabilidad XSS: inyectar etiquetas <style> o estilos en línea
• CDN comprometida: CSS malicioso servido desde una fuente de confianza
• Ataque a la cadena de suministro: paquete npm, tema o plugin comprometido
• Widgets de terceros: herramientas de chat, analítica o pruebas A/B con control de diseño

Estos ataques apuntan al navegador del usuario de diferentes maneras.

XSS y los widgets de terceros inyectan CSS malicioso directamente en la página mientras se ejecuta en el navegador del usuario.

Los ataques a CDN y a la cadena de suministro envenenan el CSS en el origen. Los ataques a CDN reemplazan tu CSS con versiones maliciosas en el servidor. Los ataques a la cadena de suministro introducen CSS malicioso en tu base de código durante la compilación mediante un paquete npm o temas comprometidos.

Engaño de interfaz en ataques basados en marcos

Algunos ataques de interfaz, como el clickjacking basado en marcos, no necesitan cambiar tu CSS en absoluto. En cambio, el atacante atrae al usuario a su propia página. Incrusta tu sitio en un iframe y disfraza visualmente en qué está haciendo clic el usuario (UI redressing). Esto solo funciona si tu sitio puede incrustarse en iframes, es decir, si no hay restricción frame-ancestors en CSP ni cabecera X-Frame-Options.

Clickjacking con SVG

El clickjacking basado en marcos puede ejecutarse mucho más allá del clásico clic en un botón oculto. En diciembre, la investigadora de seguridad Lyra Rebane compartió una prueba de concepto que lo demuestra. En lugar de depender de superposiciones clásicas, combina de forma ingeniosa filtros SVG y el renderizado CSS para crear un ataque de clickjacking interactivo y de múltiples pasos de una manera totalmente nueva. Las implicaciones son graves: si se permiten iframes incrustados, dicho ataque puede filtrar datos de origen cruzado, como se demostró con contenido de Google Docs. Conclusión: si tus páginas pueden ser enmarcadas, asume que los atacantes ya las han detectado.

Investigación independiente que amplía el clickjacking con SVG:

• https://lyra.horse/blog/2025/12/svg-clickjacking/
• https://www.theregister.com/2025/12/05/css_svg_clickjacking/

Cómo hacer CSS más seguro: prevenir, detectar, defender

CSS no puede ser weaponizado por sí solo. Los atacantes necesitan primero un punto de entrada. Una vez que ese punto de apoyo existe, CSS se convierte en un amplificador. La seguridad CSS requiere una defensa en capas con atención centrada en los escenarios que dan a los atacantes mayor ventaja con el menor esfuerzo (especialmente los flujos de inicio de sesión, consentimiento y pago).

Un enfoque práctico previene que los estilos maliciosos se carguen en el navegador, detecta la manipulación visual y defiende a los usuarios y sistemas para limitar el impacto.

Cómo prevenir ataques basados en CSS

Para prevenir ataques CSS, hay que bloquearlos desde el principio. Si impides que la inyección en línea y los estilos no confiables se carguen en el navegador, los atacantes no podrán manipular tu interfaz.

Las siguientes medidas harán que el abuso de CSS sea mucho más difícil.

1 - Controla desde dónde pueden cargarse los estilos con Content Security Policy (CSP)

Usa style-src 'self' para permitir solo estilos de tu dominio. Por supuesto, conviene evitar style-src 'unsafe-inline' en la medida de lo posible, ya que este control precisamente habilita los estilos inyectados. En caso de que necesites estilos en línea de todos modos, tiene sentido usar nonces o hashes.

No dejes que el miedo a romper cosas te detenga. Puedes probar tu CSP de forma segura antes del despliegue con CSP Report-Only.

Los informes de CSP te muestran qué se rompería. Listan los estilos en línea y las fuentes externas que serán bloqueadas, así como las dependencias de terceros que podrías haber olvidado. Corrígelas y luego aplica la política.

2 - Fija el CSS de terceros con Subresource Integrity (SRI)

Para evitar que se carguen archivos manipulados, añade SRI (integrity + crossorigin) a las hojas de estilo alojadas en CDN.

Por ejemplo:

Esto funciona mejor para activos estables y versionados, porque cada vez que la CDN actualiza este archivo, el hash cambia. Como resultado, tu verificación SRI fallará y el navegador lo bloqueará. Eso significa que tendrás que actualizar manualmente el hash de integridad. Para CSS crítico que cambia con frecuencia, es mejor alojarlo tú mismo.

Subresource Integrity es una medida de defensa sólida para archivos estáticos. Los archivos dinámicos, como JavaScript de scripts de terceros, necesitarán una solución de monitoreo continuo.

3 - Bloquea la incrustación en iframes con cabeceras anti-enmarcado

Otro gran problema son los ataques clásicos de clickjacking que incrustan tu sitio en un iframe invisible en una página fraudulenta. Content-Security-Policy: frame-ancestors 'none' y X-Frame-Options: DENY impiden que los atacantes incrusten o superpongan elementos de interfaz falsos y, en consecuencia, que engañen a los usuarios para que hagan clic en botones de los que ni siquiera son conscientes.

4 - Prevención de XSS = seguridad CSS

Los estilos en línea aumentan el riesgo y dificultan la aplicación de CSP. La forma en que previenes Cross-Site Scripting (XSS) define en gran medida tu seguridad CSS. La mayoría de los abusos de CSS dependen de una vía de inyección (a menudo XSS). Si previenes XSS, el ataque no podrá inyectar bloques <style> ni atributos style="" en línea.

Los controles preventivos como CSP, SRI y el refuerzo contra XSS reducen el riesgo, pero no proporcionan visibilidad sobre lo que realmente se renderiza para los usuarios. cside ofrece a los equipos de seguridad y cumplimiento visibilidad continua a nivel de página sobre los cambios de estilo y diseño del lado del cliente.

Cómo detectar ataques CSS: monitorear la interfaz crítica para detectar abusos

La prevención por sí sola no es suficiente. Pero no puedes corregir lo que no puedes ver. Si un ataque supera las medidas preventivas, la detección lo captura a tiempo. Así que pregúntate dónde la manipulación de la interfaz tendría mayor impacto en la seguridad y qué señales de alerta deberías buscar.

La manipulación de CSS probablemente aparece en la interfaz crítica. Es buena idea configurar alertas automáticas para las páginas de inicio de sesión, pago y privacidad/consentimiento.

1. Detección manual de CSS malicioso

Una vez que has determinado dónde buscar, vigila las hojas de estilo desconocidas que aparecen de la nada y comprueba las señales de alerta y los patrones sospechosos:

• z-index extremos que apuntan a ataques de superposición: z-index: 9999
• márgenes negativos enormes para ocultar contenido fuera de la pantalla: margin: -9999px
• mensajes de seguridad ocultos con display: none y visibility: hidden en advertencias, banners de consentimiento o mensajes de error
• Reordenamiento visual para enterrar información crítica debajo del pliegue con Flexbox order: 999
• Tamaño de fuente diminuto o bajo contraste para limitar la visibilidad en botones "Cancelar/Rechazar": font-size: 6px

Las comprobaciones de seguridad manuales pueden funcionar para proyectos pequeños y limitados; usa DevTools para buscar señales de alerta en tus páginas de inicio de sesión, pago y consentimiento. Antes de pasar a producción, prueba en móvil porque es más fácil para los atacantes ocultar contenido en una pantalla pequeña.

2. Detección automatizada de CSS malicioso

Para proyectos grandes y complejos, las comprobaciones manuales no escalan. En su lugar, incorpora la detección automática en tu sistema de monitoreo de seguridad:

• Monitoreo de seguridad en tiempo de ejecución del lado del cliente: cside detecta la manipulación del DOM y de JavaScript de forma continua en tiempo real y envía una alerta cuando se manipulan elementos críticos.
• Informes de violaciones de CSP: añade report-uri (o report-to) a tu CSP para que los navegadores reporten automáticamente las violaciones de política. Además, ejecuta un validador de CSP en cada compilación para detectar configuraciones incorrectas.
• Monitoreo sintético en páginas clave: las herramientas de regresión visual detectan cambios inesperados en la interfaz comparando capturas de pantalla. Si un botón de pago se encoge o una advertencia desaparece, lo sabrás antes que los usuarios.
• Escáneres de estilos en línea: configura tu pipeline de CI/CD para escanear estilos en línea en páginas críticas y bloquear commits antes de que lleguen a producción.

Riesgos de seguridad del CSS generado por vibe coding

Las herramientas de codificación con IA aceleran el desarrollo web y generan estilos CSS en segundos. Pero hay una contrapartida: si los equipos aceptan el CSS generado sin revisión de seguridad, también arriesgan acelerar sus vulnerabilidades de ataque.

El uso de estilos en línea conlleva el riesgo de eludir CSP; los enlaces no controlados a CDN externas sin verificaciones de integridad crean vulnerabilidades en la cadena de suministro.

Patrones CSS que deben preocuparte:

• style="display: none" disperso por todas partes (los estilos en línea complican CSP y la revisión)
• Enlaces a CSS de terceros sin Subresource Integrity (SRI)
• z-index: 999999 habilita superposiciones a pantalla completa
• Diseños complejos de Flexbox/Grid que nadie puede explicar
• CDNs de iconos y fuentes externas cargadas por defecto

Las herramientas de codificación con IA son indiferentes a tus preocupaciones de seguridad: priorizan la velocidad sobre la seguridad. Y eso se refleja en el resultado final. Los estilos en línea pueden aparecer en todas partes sin una estructura clara, lo que complica la aplicación de CSP con style-src más adelante. Las CDN de terceros de las que se obtienen temas y fuentes pueden ser atajos que crean un riesgo en la cadena de suministro.

Lee más en el artículo dedicado con consejos de defensa para código generado por IA.