Comparing React and Angular secure coding practices
October 30, 2019
0 mins readWelcome to Snyk's State of JavaScript frameworks security report 2019. This section of the report is about Angular and React projects overall security posture.
In this section, we explore both the Angular and the React project security postures. This includes secure coding conventions, built-in in secure capabilities, responsible disclosure policies, and dedicated security documentation for the project.
The following table lays out a few of the security components we found to be essential for best-practice maintenance of any open source package, and an indication of how Angular and React manage said components (if at all).
Item | Angular | React |
Security page | ✅ https://angular.io/guide/security | ❌React’s website (https://reactjs.org) does not mention any security guidelines, except for the dangerouslySetInnerHTML function reference in the DOM Elements section of the API Reference documentation. |
Security contact | ✅security@angular.io | ❌No security contact |
Responsible disclosure policy | ✅Backed by the internal security teams at Google and based on Google security philosophy. Reference: https://www.google.com/about/appsecurity/ | ❌No responsible disclosure policy |
Examples of vulnerable projects | ✅https://angular.io/generated/live-examples/security/stackblitz. html | ❌No references to any examples of vulnerable projects |
Built-in sanitization | ✅DomSanitizer provides a built-in sanitization function for untrusted values. Reference: https://angular.io/api/platform-browser/DomSanitizer#sanitize | ❌Potentially malicious input sanitization is at the users' discretion to be implemented via 3rd-party libraries, such as DOMPurify. Reference: https://github.com/cure53/DOMPurify |
Content Security Policy (CSP) | ✅CSP compatibility for Angular v1.x directives. Reference: https://docs.angularjs.org/api/ng/directive/ngCsp | 🔘Not relevant for React |
✅CSRF built-in support through Angular’s HttpClient service. Reference: https://angular.io/guide/http and https://docs.angularjs.org/api/ng/service/$http | 🔘Not relevant for React as a view library. This is up to the developers to handle using custom code or community modules. |
Angular secure coding practices
Angular v2 and later, have a completely different architecture than Angular v1, such as unidirectional data binding. What’s more, the v2 and later versions have left automatic data interpolation via watchers behind, as well as other techniques that were often the cause for many of the Angular v1 security vulnerabilities.
Ahead of Time (AoT) compilation mitigates issues such as Angular templating expression injection and allows for build-time security instead of run-time security. However, dynamically interpolating templates on the client-side still leaves the door open for security vulnerabilities in the form of Angular code injection. In their own best practices documentation, Angular clearly emphasize that this dynamic interpolating is highly unadvisable. With respect to Angular’s documentation, these are highly discouraged as Angular’s best practices clearly point out.
To mitigate cross-site scripting vulnerabilities, Angular employs by default context-aware output encoding, or malicious code sanitization. Moreover, method naming conventions are much better understood, in terms of their impact, if a developer consciously chooses to use them, as opposed to earlier Angular versions, namely Angular v1.x.
Methods such as bypassSecurityTrustHtml(value)or bypassSecurityTrustUrl() implicitly convey the dangers of using them to insert data into the DOM. Moreso, Angular provides a built-in DomSanitizer to explicitly sanitize values.
React secure coding practices
React by default encodes almost all data values when creating DOM elements. To provide users with an escape hatch to insert HTML content into the DOM, React is equipped with the eloquently-named function dangerouslySetInnerHTML(), clearly conveying the dangers of using it.
Contexts that are unattended by the React security model and are handled by the users include creating:
HTML anchor (link) elements with user- provided input as the source for the href attribute value. This mostly applies to versions prior to the recently released React v16.9 which mitigates javascript:-based URLs in href attribute values and other contexts such as form actions, iFrame sources, and others.
React components from user-provided input
React’s server-side rendering could potentially introduce XSS vulnerabilities if malicious user input is injected as-is to a JavaScript context without being properly encoded or sanitized.
HTTP security
Starting with version 1.2, Angular v1.x release branches have introduced compatibility support for Content Security Policy (CSP) which is necessary due to the use of eval() and Function() methodology to interpolate expressions.
Cross-Site Request Forgery (CSRF) enables web applications to trust the origin of a request. In newer Angular versions, CSRF support mechanism is built-in to the HTTP client with the @angular/common/ http module. In Angular v1.x versions similar capability is supported through the $http provider.
Unlike Angular, React doesn’t include an HTTP client and as such, it is unable to provide CSRF support out-of-the-box. As React aims to be a minimalistic view library, handling this concern is up to the developer, using custom code or community-powered modules.
We highly recommend downloading the full version of the report in its digital format, but have also made the following general sections available as blog posts: