The popular use of single page applications 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:
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.
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.
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.
Session Tracking and Authentication
Browsers running in single-page 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:
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.
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.
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.
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.