Contact us anytime to know more — Abhishek P., Founder & CFO CISIN
It is advisable that you should never implement an independent client-side security layer in AngularJS application or any other Javascript application.
Backend services is a safe place to implement a security layer, so that security should always be implemented on the backend services where the data resides
AngularJS deals with all client side components and activities, therefore, it is considered as purely client side framework or technology.These client-side activities comprise of dealing with secure (HTTPS) and non-secure websites, handling cookies, scripting across clients and much more.It is especially obvious that AngularJS will not be taking care of your network or server security.
Best Practices
The security defects which you may have found in past versions can be fixed.So that Always ensure that you consistently refresh the Angular libraries.
Additionally, check the Angular change log for other security-related updates.
There are chances that customized versions of Angular can fall behind the current version and may not include important security fixes and enhancements ,so that Don’t modify your copy of Angular
Let us discuss in detail about security concerns and remedies if any.
1. Ensure requests originate from your web application only
When user visit on a specific website (such as a bank website)Attackers/hackers can steal the session information and execute actions on your behalf (such as transfer money from your account to their account).The request could originate from different sources such as following:
Open attackers’ websites
Open of attackers’ website through a link send in your email.
Hacking session information and do undesired activities from accessing an image send by hacker.
Following approaches to create your anti-XSRF & anti-CSRF code:
XSRF-TOKEN cookie get a randomly generated authentication token which is send by Application server code.
Client code allow to read the cookie and X-XSRF-TOKEN request header, in all subsequent requests.
compares the received cookie value X-XSRF-TOKEN with XSRF-TOKEN with help of server code and refuse the request if the values are missing or don’t match.
Provide built-in support for applying checks on the client side with the help of HttpClient.
Implementation of same origin policy to ensure that only code from the website on which cookies are set can read the cookies from that site and set custom headers on requests to that site.
2. User's Submitted Data should Sanitize
If a value is trusted for the context, this sanitize method will (in case of a SafeValue) unwrap the contained safe value and use it directly.
else, based on security context the value will be sanitized to be safe.
Helper functions mainly have three types for sanitizing the values.sanitizeHtml perform sanitizes on untrusted HTML value by parsing the value and checks its tokens.
The sanitizeStyle and sanitizeUrl functions sanitize the untrusted style or URL value by regular expressions.For marking a value as trusted, one injects DomSanitizer and call one of the following methods:
- bypassSecurityTrustHtml
- bypassSecurityTrustScript
- bypassSecurityTrustStyle
- bypassSecurityTrustUrl
- bypassSecurityTrustResourceUrl
Selection of context decide Whether the value is safe or not, hence choose rightly the context for your intended use of the value.
Preferably, Angular consequently sanitizes the URL and it disables the dangerous code in development mode and logs this action to the console.
3. Inspect/Validate Users’ Submitted Data on Server-side code
Injecting executable code into the application is the same as injecting template code into an Angular application.
So, preventing XSS vulnerabilities on the server user should validate all data on server-side code and escape it appropriatelyAlso, not to generate Angular templates on the server side using a template language as per Angular recommendation.
4. Use OTC
Binding expressions in templates, HTML and attributes are trusted to be safe. This implies we have a security leak if an attacker can control a value that is being parsed by the template
Never create template source code by associating user input and templates. By using of offline template compiler, otherwise called template injection to prevent these vulnerabilities
it’s easy to enable AOT using Angular CLI
ng serve --aot
ng build --aot
5. Content Security Policy (CSP)
Data injection attacks and Cross Site Scripting (XSS) such type of attacks are detect and mitigate by an additional layer of security that is called Content Security Policy (CSP)
These attacks are utilized for everything from data theft to changes the visual appearance of the website or Malware distribution.
For enabling CSP, we server need to be configure to return an appropriate Content-Security-Policy HTTP header. You can find a very detailed manual how to enable CSP on the MDN website.
Use CSP evaluator from Google to check validity of your CSP.
6. Avoid interacting directly with the DOM’s APIs
Use Angular templates wherever required and avoid interacting directly with the DOM .In-built browser DOM APIs do not automatically protect from security issues.
7. Make JSON responses Non-Executable by adding Prefix
The security risk/vulnerability misuses part of executing JSON response as Javascript. Misuses of JSON response can be avoide by prefixing the JSON response with the string like “)]}’,\n” and enabling client-side processing of stripping the previous notice string from all JSON response by proper parsing.
“Anti-XSS protection” by adding )]}' before ajax response`
Angular HttpClient provides this as out-of-box functionality of stripping the JSON responses of “)]}’,\n”.
8. At regular intervals update the Angular libraries
For feature enhancements The angular team is doing releases at regular intervals, bug fixes and security patches as appropriate.
In this manner, it is prescribed to refresh the Angular libraries at regular intervals. Neglecting to refresh Angular libraries with most recent releases may enable attackers to attack the application using security vulnerabilities present with older releases if any.
9. Modifying the Angular Copy must avoid
Ensure that it doesn't make hard connections in between your application and angular versions to such an extent that you unable to get current Angular versions.
10. Audit & Test Everything at Regular Intervals
Following security implementations must be regularly code reviewed/audited and tested:
- Usage of API such as bypassSecurityTrustXXX including escaping Angular default XSS implementation of not trusting any data.
- XSRF cookie implementation related matching cookie data sent in response header (XSRF-TOKEN) to that with cookie data sent in request header (X-XSRF-TOKEN)
- libraries of Angular update Regularly
- APIs of Angular marked as security risk should not be used.
Stay Secured
As a developer always remember that any security-related JavaScript code can be easily viewed and modified by the user.
In spite of the fact that most present day browsers do offer built-in security, yet at the same time JS developers ought to never trust browsers for security. The whole responsibility of security lays on shoulders of backend service developers
