Comparación de las prácticas de codificación segura de React y Angular
30 de octubre de 2019
0 minutos de lecturaTe damos la bienvenida al informe State of JavaScript Frameworks Security Report 2019 de Snyk. Esta sección del informe trata sobre la postura general de seguridad de los proyectos Angular y React.
En esta sección, exploramos la postura de seguridad de los proyectos Angular y React. Esto incluye convenciones de codificación segura, capacidades de seguridad integradas, políticas de divulgación responsable y documentación de seguridad específica para cada proyecto.
La siguiente tabla presenta algunos de los componentes de seguridad que consideramos esenciales para el mantenimiento según las mejores prácticas de cualquier paquete de código abierto, e indica cómo Angular y React gestionan esos componentes (si es que lo hacen).
Elemento | Angular | React |
Página de seguridad | ✅ https://angular.io/guide/security | ❌El sitio web de React (https://reactjs.org) no menciona ninguna guía de seguridad, salvo la referencia a la función dangerouslySetInnerHTML en la sección DOM Elements de la documentación de referencia de la API. |
Contacto de seguridad | ✅security@angular.io | ❌No hay un contacto de seguridad |
Política de divulgación responsable | ✅Cuenta con el respaldo de los equipos de seguridad internos de Google y se basa en la filosofía de seguridad de Google. Referencia: https://www.google.com/about/appsecurity/ | ❌No hay una política de divulgación responsable |
Ejemplos de proyectos vulnerables | ✅https://angular.io/generated/live-examples/security/stackblitz. html | ❌No hay referencias a ejemplos de proyectos vulnerables |
Sanitización integrada | ✅DomSanitizer proporciona una función de sanitización integrada para valores que no son de confianza. Referencia: https://angular.io/api/platform-browser/DomSanitizer#sanitize | ❌La sanitización de entradas potencialmente maliciosas queda a criterio de los usuarios, quienes pueden implementarla con bibliotecas de terceros, como DOMPurify. Referencia: https://github.com/cure53/DOMPurify |
Política de seguridad del contenido (CSP) | ✅Compatibilidad con CSP para las directivas de Angular v1.x. Referencia: https://docs.angularjs.org/api/ng/directive/ngCsp | 🔘No es relevante para React |
✅Compatibilidad integrada con CSRF mediante el servicio HttpClient de Angular. Referencias: https://angular.io/guide/http y https://docs.angularjs.org/api/ng/service/$http | 🔘No es relevante para React como biblioteca de vistas. Los desarrolladores deben gestionarlo con código personalizado o módulos de la comunidad. |
Prácticas de codificación segura de Angular
Angular v2 y las versiones posteriores tienen una arquitectura completamente distinta a la de Angular v1, por ejemplo, con el enlace de datos unidireccional. Además, las versiones v2 y posteriores dejaron atrás la interpolación automática de datos mediante observadores, así como otras técnicas que a menudo eran la causa de muchas de las vulnerabilidades de seguridad de Angular v1.
La compilación Ahead of Time (AoT) mitiga problemas como la inyección de expresiones en plantillas de Angular y permite aplicar seguridad durante la compilación en lugar de durante la ejecución. Sin embargo, la interpolación dinámica de plantillas en el cliente sigue dejando abierta la posibilidad de vulnerabilidades de seguridad en forma de inyección de código de Angular. En su documentación de mejores prácticas, Angular deja claro que esta interpolación dinámica es muy poco recomendable. Según la documentación de Angular, estas prácticas se desaconsejan firmemente, tal como se indica claramente en sus mejores prácticas.
Para mitigar las vulnerabilidades de secuencias de comandos entre sitios, Angular emplea de forma predeterminada la codificación de salida según el contexto o la sanitización de código malicioso. Además, las convenciones de nomenclatura de métodos permiten entender mucho mejor su impacto cuando un desarrollador decide usarlos conscientemente, a diferencia de las versiones anteriores de Angular, en particular Angular v1.x.
Métodos como bypassSecurityTrustHtml(value) o bypassSecurityTrustUrl() comunican claramente los peligros de usarlos para insertar datos en el DOM. Además, Angular proporciona DomSanitizer, una herramienta integrada para sanitizar valores de forma explícita.
Prácticas de codificación segura de React
De forma predeterminada, React codifica casi todos los valores de datos al crear elementos DOM. Para permitir que los usuarios inserten contenido HTML en el DOM, React incluye la función dangerouslySetInnerHTML(), cuyo nombre comunica claramente los peligros de usarla.
Entre los contextos que no contempla el modelo de seguridad de React y que deben gestionar los usuarios se encuentran los siguientes:
Crear elementos de anclaje (enlaces) HTML con entradas proporcionadas por el usuario como valor de origen del atributo href. Esto se aplica principalmente a las versiones anteriores a React v16.9, lanzada recientemente, que mitiga las URL basadas en javascript: en los valores del atributo href y en otros contextos, como las acciones de formularios, las fuentes de iFrame y otros.
Componentes de React a partir de entradas proporcionadas por el usuario
La representación del lado del servidor de React podría introducir vulnerabilidades XSS si se inyecta una entrada maliciosa del usuario tal cual en un contexto de JavaScript, sin codificarla ni sanitizarla correctamente.
Seguridad HTTP
A partir de la versión 1.2, las ramas de lanzamiento de Angular v1.x incorporaron compatibilidad con la Política de seguridad del contenido (CSP), necesaria debido al uso de los métodos eval() y Function() para interpolar expresiones.
La falsificación de solicitudes entre sitios (CSRF) permite que las aplicaciones web confíen en el origen de una solicitud. En las versiones más recientes de Angular, el mecanismo de compatibilidad con CSRF está integrado en el cliente HTTP mediante el módulo @angular/common/ http. En las versiones de Angular v1.x, se admite una capacidad similar a través del proveedor $http.
A diferencia de Angular, React no incluye un cliente HTTP y, por lo tanto, no puede ofrecer compatibilidad con CSRF de forma inmediata. Como React busca ser una biblioteca de vistas minimalista, el desarrollador debe encargarse de este aspecto mediante código personalizado o módulos desarrollados por la comunidad.
Te recomendamos ampliamente descargar la versión completa del informe en formato digital. También publicamos las siguientes secciones generales en forma de artículos de blog:
El informe State of JavaScript Frameworks Security Report 2019
Comparación lado a lado de las vulnerabilidades de seguridad de Angular y React en 2019
Angular vs. React: el riesgo de seguridad de las dependencias indirectas
El 84 % de todos los sitios web se ven afectados por vulnerabilidades XSS de jQuery
