5 (Practical) Tips to Help You Secure Your Single Page Application
Table of Contents
What is A Single Page Application
Jeff Nibler describes Single Page Applications (SPAs) as the latest evolution in web application design. With SPAs, various JavaScript libraries and tools such as Jquery, Angular allow developers to create web applications that very rarely call the server to fetch a whole new HTML page. Instead, the single HTML page is broken up into sections and JavaScript code running in the web browser calls various APIs on a server that return data. The JavaScript libraries then take this data and update the HTML on the page according to the presentation logic the developer coded into the application. Single page applications remove the presentation layer from the server side and put it on the client-side, in the browser.
The more interactivity that happens on the client-side, the more JavaScript code is needed to make those interactive pieces function well. And the more code is written, the more important it is to have a clean and well-architected codebase. And this is exactly the problem JavaScript frameworks help solve — each with its own approach. There are a lot of open source JavaScript frameworks that help with building SPAs, such as Angular, React, Ember, Aurelia, Vue.js, Cycle.js, and Backbone, to name the most popular ones.
Advantages of Single Page Applications
The Angular University lists some of the advantages of Single Page Applications (SPA):
1. Best responsiveness – Server-side rendering is hard to implement for all the intermediate states – small view states do not map well to URLs. Single page apps are distinguished by their ability to redraw any part of the UI without requiring a server roundtrip to retrieve HTML. This is achieved by separating the data from the presentation of data by having a model layer that handles data and a view layer that reads from the models.
2. Easy to deploy – A single page application is super-simple to deploy if compared to more traditional server-side rendered applications: it’s really just one index.htmlfile, with a CSS bundle and a Javascript bundle. These 3 static files can be uploaded to any static content server like Apache, Nginx, Amazon S3 or Firebase Hosting.
3. Versioning and rollback – Another advantage of deploying our frontend as a single page application is a versioning and rollback. All we have to do is to version our build output (that produces the CSS and JS bundles highlighted in yellow above). We can configure the server that is serving our SPA with a parameter that specifies which version of the frontend application to build. This type of deployment scales very well: static content servers like Nginx can scale for a very large number of users.
4. Faster to load – If you have ever used a web application that is constantly reloading everything from the server on almost every user interaction, you will know that that type of application gives a poor user experience due to: the constant full page reloads; also due to the network back and forth trips to the server to fetch all that HTML. On a SPA, after the initial page load, no more HTML gets sent over the network. Instead, only data gets requested from the server (or sent to the server). So while a SPA is running, only data gets sent over the wire, which takes a lot less time and bandwidth than constantly sending HTML. Let’s have a look at the type of payload that goes over the wire typically in a SPA.
Some Disadvantages of Single Page Applications
On the other hand, opinion leaders such as Daniel Puplus and Adam Silver insist that Single Page Applications (SPA) have more cons than pros and will therefore not survive. Example claims include the following:
1. History and fastback – In the traditional web model, the browser will typically be able to use a cached version of the page and linked resources. In a naive implementation of a SPA hitting back will do the same thing as clicking a link, resulting in a server request, additional latency, and possibly visual data changes.
2. Scroll position – Lots of sites get this wrong and it’s annoying. When the user navigates using the browser’s forward or back button the scroll position should be the same as it was last time they were on the page. This sometimes works correctly on Facebook but sometimes doesn’t.
3. Unsaved changes – An application, upon leaving the page, will warn users about losing any unsaved changes. The browser allows us to use the before unload event to do just this. However, the application cannot use this feature because users don’t request real pages. Meaning, the application will need to reimplement this behavior if needed.
4. Loading CSS & Javascript – If a SPA grows to a significant size, loading the entire application on page load will be slow. This leads to conditionally loading CSS and JS with a script loader.
5. Memory leaks – Pages are “long lived” increasing the chance of memory leak issues. This can degrade UX and because of battery drain on mobile devices.
UI and memory issues are indeed challenging that any software architect will have to deal with when considering the building of a Single Page Application. But what about Security issues?
Security Issues with Single Page Applications
Security issues are not unique to SPAs, It’s just that the user is making the requests rather than your JavaScript, and that the results are in HTML rather than JSON or some data format. 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. The following challenges are most common security issues that Single Page applications face:
1. General API Security – Single Page Applications are causing many companies to publish public APIs for the first time, or to increase the number of publicly exposed APIs. Many companies are familiar with and have the tools in place to secure web applications, and these web applications may call business services on the back end but the business services themselves don’t require the same level of security that a publicly exposed API does because they are not directly exposed to the internet.
2. Authentication and Session Tracking – Browsers running in single page web applications may be interacting with two completely different systems: One to load one or several HTML web pages and possibly provide assets such as images and JavaScript libraries, and another to serve the API calls that contain the business logic and data. In some cases, the APIs behind a single page application can be protected by web server sessions just like they were in the traditional approach, but this requires all business APIs to be proxied by a web server and doing so usually requires the use of session cookies.
3. Cross Site Scripting (XSS) Attacks – occur when a vulnerable application allows arbitrary javascript code to be injected and executed on your page. This often occurs through the form fields on the page.
4. Cross Site Request Forgery (CSRF) – occurs when a malicious website, email, blog, instant message or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. CSRF occurs when a malicious site has a link or form that connects to another site that you are already logged into.
When building SPA style applications using frameworks like Angular, Ember, React, etc. what do people believe to be some best practices for authentication and session management. Here are some of the suggestions that the community recommends as best practices for securing single page applications:
1. HTTP Basic Authentication – The simplest of schemes: simply pass a name and password with every request. This requires SSL and is the most RESTful solution. The server requires no knowledge of state whatsoever and authenticates every individual interaction with the user. The problem with this is that you are caching on the client-side a username and password. Even the most basic of XSS vulnerabilities could result in the client beaming his username and password to an evil server.
2. Tokens with an Expiry Policy – The user sends a username and password, and in exchange gets a token that can be used to authenticate requests. This is marginally more secure than HTTP Basic Authentication, because as soon as the username/password transaction is complete you can discard the sensitive data. It’s also less RESTful, as tokens constitute “state” and make the server implementation more complicated. Best practices wise, it is also common to enforce token expiry policies.
3. SSL – You still must send that initial username and password to get a token. Sensitive information still touches your JavaScript. To guard your user’s credentials, you still need to keep attackers out of your JavaScript, and you still need to send a username and password over the wire.
4. Continuously checking your code for security vulnerabilities – For proprietary code, this is day-to-day practice, using an application security tool. For open source code, this is a feasible step, using an open source management tool. The key tip here is to use such an open source management tool, in a continuous manner, in real time, during the build phase of the development lifecycle, sprint after sprint.
5. Separate sensitive data to a secure zone – The larger the application that you’re running, the harder it is to absolutely ensure that they won’t be able to inject some code that changes how you process sensitive data. Common for credit card based applications and less common for username and password – some implementers keep ‘sensitive data entry’ on a separate page from the rest of their application, a page that can be tightly controlled and locked down as best as possible, preferably one that is difficult to phish users with.
