Cómo usar de forma segura un framework frontend para tu sitio web
por Tristan Wieffering
Security Specialist¿Qué es un Framework Frontend?
Un framework es un conjunto de herramientas—un punto de partida para desarrollar tu sitio web. Estandariza la forma en que estructuras tu software, el código, y se encarga de muchas cosas que todo sitio web necesita, como el almacenamiento de datos o la construcción de páginas. Esto último es un ejemplo principal de lo que un framework ofrece para el "frente" del sitio web, de ahí el nombre framework frontend. Basándonos en nuestras experiencias con vulnerabilidades en la práctica, aquí están los tres consejos más importantes para usar frameworks frontend de manera segura.
1. No Confíes en Tu Frontend
El frontend se llama frontend porque es la parte del código del sitio web que se ejecuta en la computadora, laptop o dispositivo móvil del visitante. Esto significa que no debes confiar en el frontend. Alguien con intenciones maliciosas puede fácilmente ver o modificar el código fuente del frontend. Por lo tanto, es crucial que el backend, la parte del servidor del sitio web, no dependa del frontend para realizar verificaciones de seguridad; debe hacerlas de forma independiente. Esto incluye verificar la autenticación del usuario y si un usuario autenticado tiene acceso a datos sensibles. Además, el código fuente del frontend es público, por lo que no es el lugar para información sensible o secretos como contraseñas o claves API.
2. Conoce las Limitaciones de Tu Framework
Un framework frontend es increíblemente útil, especialmente para prevenir una vulnerabilidad particular que afecta a un tercio de los sitios web: el cross-site scripting (XSS). Si un sitio web es vulnerable a XSS, una persona malintencionada puede usar un fragmento de código dañino para atacar a otros visitantes del sitio. Normalmente, el atacante no puede dirigirse a todos en el sitio sin pasos adicionales, como hacer que la víctima haga clic en un enlace malicioso específico.
Los frameworks frontend son herramientas efectivas para prevenir vulnerabilidades XSS ya que muchos aplican automáticamente la codificación correcta, asegurando que la entrada se renderice como datos en lugar de código. A pesar de esto, los frameworks frontend no son soluciones mágicas, y debes tener en cuenta muchas excepciones como desarrollador. Profundizaremos en detalles en breve. Si no eres desarrollador, puedes saltar al punto 3 sobre actualizaciones.
2.1 Teoría de los Frameworks
El cross-site scripting surge cuando la entrada del usuario llega a lugares en el frontend donde no se interpreta como texto sino como HTML o JavaScript. Por ejemplo, si construimos una función de búsqueda que muestra cuántos resultados produjo un término de búsqueda, podríamos olvidar codificar en HTML el término de búsqueda. Esta omisión permite la creación de enlaces con JavaScript malicioso que, al hacer clic, ejecuta ese código. Con JavaScript, los atacantes obtienen acceso a datos sensibles de la víctima.


Esencialmente, hay tres variantes básicas de XSS, categorizadas según dónde termina la entrada del usuario. En el ejemplo anterior, termina entre etiquetas de elementos, en 'innerHTML', pero el XSS también puede ocurrir con entradas colocadas en un atributo HTML.


Por último, existe una variante única que involucra prefijos especiales de URL como 'javascript:'


2.2 XSS y Frameworks Frontend
Algunos frameworks protegen rigurosamente contra las tres variantes básicas de XSS, mientras que otros solo protegen contra la primera. Examinemos tres frameworks.
2.2.1 Angular
-
Si usas consistentemente la interpolación en Angular ({{ }}), estás protegido. Angular es lo suficientemente inteligente para reconocer los contextos mencionados anteriormente. Sin embargo:
-
No anules las funciones de seguridad de Angular. Puedes marcar cierto contenido como seguro usando funciones como bypassSecurityTrustHTML, pero esto evita la función de escape de Angular y representa un riesgo de vulnerabilidades XSS.
-
Evita generar plantillas dinámicamente, como agregar cadenas a plantillas o usar otro lenguaje de plantillas. El escape solo ocurre durante el renderizado de la plantilla, por lo que la plantilla en sí debe ser confiable. Cualquier entrada de usuario incorporada en la plantilla representa riesgos de XSS.
2.2.2 Vue.js
Vue.js también ofrece un soporte fuerte. Al usar interpolación de texto ({{ }}), la entrada del usuario se codifica en HTML, haciéndola segura para inclusión entre etiquetas HTML. No obstante, considera:
-
En la mayoría de los casos, la entrada del usuario en enlaces de atributos dinámicos es segura, pero se debe tener precaución con atributos como 'src' y 'href', ya que Vue.js solo codifica las comillas dobles ("). Por lo tanto, un prefijo 'javascript:' podría persistir.
-
Vue.js permite manejadores de eventos con directivas v-on o directamente en atributos de eventos 'nativos', pero cuidado: la entrada del usuario en tales atributos se trata y ejecuta como JavaScript. La codificación HTML mediante interpolación de texto hace poco, ya que la entrada no está en un contexto HTML sino en uno JavaScript.
-
Similar a Angular, la manipulación directa del DOM en Vue.js, como usar v-html, funciones de renderizado o JSX, interpreta la entrada como HTML, representando riesgos cuando se combina con entrada (potencial) del usuario.
-
Como en Angular, generar plantillas dinámicamente en Vue.js es riesgoso. El escape ocurre al renderizar, por lo que plantillas no confiables debido a entrada de usuario añadida representan riesgo de XSS.
2.2.3 React
-
React sigue una línea similar. JSX sirve para definir elementos HTML, evaluando el contenido JSX como expresiones JavaScript, que luego se codifican en HTML, asegurando un contenido seguro entre etiquetas HTML. Sin embargo, ten en cuenta:
-
React también solo escapa las comillas dobles (") en atributos. Por lo tanto, ten precaución con los atributos 'src' y 'href' donde podrían permanecer prefijos 'javascript:'.
-
En React, la manipulación directa del DOM mediante dangerouslySetInnerHTML o interacción con el DOM usando findDOMNode/createRef omite el escape estándar de React, dejando vulnerabilidades XSS.
-
Es común en React instanciar componentes usando el operador spread (por ejemplo, <div { ...properties }>). Sin embargo, un usuario que modifique el objeto de propiedades puede inyectar script a través de 'dangerouslySetInnerHTML', resultando en exposición a XSS.
3. Mantén el Software Actualizado
Las actualizaciones de software y la gestión de dependencias siempre son un desafío de seguridad, ciertamente para frameworks frontend. Es crucial revisar periódicamente nuevas vulnerabilidades ya que surgen frecuentemente y pueden afectar tu situación. Las herramientas pueden ayudar; muchos gestores de paquetes pueden verificar automáticamente vulnerabilidades conocidas (como npm audit), mientras que escáneres de dependencias pueden crear solicitudes de actualización automáticamente (como Dependabot).
Finalmente, sé crítico con el software del que dependes. Cada biblioteca adicional aumenta tu superficie de ataque, posiblemente albergando vulnerabilidades desconocidas, necesitando actualizaciones oportunas y potencialmente siendo comprometida. Por ello, limita las dependencias de software y usa solo fuentes confiables.
Conclusión
¿Quieres usar un framework frontend de forma segura? Aquí te decimos cómo:
- No confíes en tu frontend. Usa el backend para secretos y verificaciones de seguridad vitales.
- Sé consciente de las limitaciones de tu framework. Un framework solo es más seguro si se usa correctamente.
- Monitorea las actualizaciones de software y asegura parches de seguridad oportunos.
¿Tienes curiosidad si tu frontend es seguro? Permítenos revisar tu código fuente. Realizaremos una investigación profunda para identificar vulnerabilidades y proporcionar retroalimentación sobre elecciones arquitectónicas y de diseño, ayudándote a abordar debilidades.
Contáctanos en: [email protected].

