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.
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.
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.
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?
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.
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.
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.