Security for Single Page Applications

Since web applications keep growing, so do the challenges that we need to take to maintain a high level of trust and security for them. A lot of companies have aimed to single-page applications (SPAs) to provide a better experience with fewer development efforts. The popular use of this technology provides a challenge for security teams looking to decrease their risk of a breach, as traditional scanning methods may not provide the necessary coverage. This is disturbing because according to the studies, web applications were involved in 43% of all breaches.

SPAs security risks

Security issues are not unique to SPAs. In a non-SPA, you have to secure the individual pages on the server, whereas in a SPA app you have to secure the data endpoints. These are the most common security issues faced by this type of applications:

1. Data exposure via API — SPAs typically present data to the client via an API. It is important to remember to put adequate authorization which will check on what data is returned in requests because it is easy for sensitive data to be exposed to other users.
2. Cross-Site Scripting (XSS) Attacks — Using XSS, attackers can inject malicious client-side scripts into web applications. Single-page apps may be more sensitive to cross-site scripting (XSS) attacks than multi-page applications because of the greater reliance on client-side scripting for their functionality to manipulate user input. This type of attack occurs when a vulnerable application allows arbitrary JS code to be injected and executed on your page. It usually happens for example through the form fields.
3. Cross-Site Request Forgery (CSRF) — CSRF or XSRF or sea-surfing is one of the oldest web application attacks. CSRFs are performed through social engineering, for example, via forged emails or links that trick the user into sending a fake request to the server. It happens when a malicious website has a link that connects to another website that the user has already signed in to. The bad actors authenticate the unaware user, so it is nearly impossible to distinguish a legitimate request from a fake one.
4. Session Tracking and Authentication — Browsers running in single-page web applications may be interacting with two different systems:

• one which loads one or several HTML web pages and provides assets such as images and JS libraries
• another which serves the API calls that contain the data and business logic.

The APIs behind a single page application can be protected by web server sessions (just like in the traditional approach), but it requires all business APIs to be proxied by a web server, which usually requires the use of session cookies which are very vulnerable to cyber-attacks.

Tips to secure Single-Page Applications

Here are some of the suggestions recommended as best practices for securing single-page applications:

1. HTTP Basic Authentication — Pass a name and password with every API request. This requires SSL and is the most RESTful solution. The server requires no knowledge of state and authenticates every single interaction with the user. The only problem is that you are caching a username and password on the client-side. Even the most basic of XSS vulnerabilities could result in the client beaming his username and password to a hacker server.

2. Tokens with an Expiry Policy — Send a username and password, and in exchange get a token that can be used to authenticate requests. It is more secure than HTTP Basic Authentication because the data is encrypted and as soon as the username/password transaction is complete you can discard the sensitive ones. For better security, it is also common to enforce token expiry policies.

3. SSL — The user also needs to send that initial username and password to get a token. Sensitive information still reaches your JavaScript. To guard your user’s credentials, you furthermore need to keep attackers out of your JavaScript, and you still need to send a username and password over the wire.

4. Regularly checking code for security vulnerabilities — This is day-to-day practice, making penetration tests or using an application security tool.

Pen testers can find all levels of vulnerabilities attacking the application manually. The downside of using only pen testing is the lack of scalability across the application portfolio, which prevents frequent testing.

The second solution is to use automated security scanning technologies. Organizations need to use a Dynamic Analysis solution that has the ability to automatically and effectively scan SPAs. Because the scanners simulate real-world user actions inside a browser instead of simply observing network traffic, it can navigate through the SPA, until the application is successfully scanned.

5. Separate sensitive data to a secure zone — The larger the application, the harder it is to absolutely ensure that hackers won’t be able to inject some code that changes how you process sensitive data. It is common for credit card based applications and less common for username and password — some developers keep ‘sensitive data entry’ on a separate page from the rest of their application, that can be tightly controlled and locked down as best as possible.