Mitigating the Dangers of Single-Page Applications

Single-Page Applications (SPAs) took the software world by storm. After all, could anything be more important than a seamless user experience?

Well, if you ask me, secure data is equally as important. And SPAs are far more challenging to secure than traditional multi-page web applications. In this article, you’ll learn about security concerns in SPAs. Understanding these risks is vital for anyone who wants to work in software development or application security.

Some popular single-page applications.

How to Avoid Excessive Data Exposure in SPAs

Client-side data storage is the magic behind single-page applications. Naturally, client-side data storage goes against security best practices, which can lead to conflict. Luckily, there are ways to safely manage data.

Implement Server-Side Verification of User Identity and Privilege

Implement server-side authorization checks to ensure users are served only the correct data. These checks should include the identity of the user, along with roles or group permissions they’ve been granted.

Display Only Authorized Data

Logging in is a common prerequisite to accessing SPAs. This means users are authenticated and, as a result, they have proper authorization for the data that’s loaded. If you’re going to display data to unauthenticated users, ensure that data is considered public record.

Set Session Timeouts for Inactivity

When a user accesses an application, their login period is called their “session.” The persistence of a session, or how long it lasts, is affected by a few factors. 

First, the session typically ends if all tabs/windows of an application are closed. This is considered a security best practice. If the user navigates back to the app, it’s common to require them to login again to prevent access by an unauthorized party.

Second, a period of inactivity typically ends a session. Terminating inactive sessions decreases the likelihood of hijacking by another party. A general rule to use is the more sensitive the data, the shorter the inactivity period should be prior to a forced logout.

Use AJAX Requests to Minimize Data Exposure

Google invented AJAX to solve the problem of asynchronous loading on web pages. Luckily for us, it means we don’t need to render 100% of the data on the initial page load. If there are certain types of data that are particularly sensitive, you can require a user to submit an additional action before those are displayed. You can even place a separate timeout counter on the sensitive information to shorten its persistence.

Additional data requests are also an opportunity to confirm the user’s identity via multi-factor authentication (MFA). For example, on some stock market trading apps, attempting to buy or sell a stock triggers an MFA event.

Be Strategic with Data Stored in LocalStorage

The client-side data must be stored somewhere. Enter: localStorage.

LocalStorage allows developers to include information within the browser that’s needed at later points in time. This data is typically stored in plaintext format – and it introduces some issues.

One common pitfall is not authorizing user permissions after login. It’s common that modifying plaintext values within localStorage will change the user interface (UI). For example, setting a value of “admin: true” may reveal additional options within a UI. Any user attempting to access administrative controls should have their authorization validated by the server.

A second pitfall is storing JSON Web Tokens (JWTs) inside localStorage. JWTs allows the server to cryptographically verify a user which makes them quite powerful. If your JWT is stolen via cross-site scripting (XSS), the attacker can easily impersonate you. It’s considered best practice to store JWTs inside of httpOnly cookies with the sameSite flag set to true and include an Anti-CSRF (Cross-Site Request Forgery) token.

LocalStorage object that allows users to appear as administrators.

Consider Your Cross-Site Scripting Blast Radius

We mentioned how cross-site scripting (XSS) can result in token theft. But, as you have seen throughout this article, there’s often a greater quantity of personal information stored in the browser of SPAs. What does that mean for you? SPAs have an increased risk of data compromise during an XSS attack. Any sensitive data that’s pre-loaded into localStorage is at risk.


Single-page applications are many software team’s first choice. When secured appropriately, they’re the ultimate user experience. If you want to see a hands-on example of localStorage manipulation, check out this walkthrough video I created.






Interested in more educational content on application security? Here are a bunch of videos I created.

Did you find this blog helpful or interesting?

Click the social media button of your choice to share the blog with you friends and colleagues.

See a Live Demo of the Bionic Platform

CrowdStrike Bionic

Have you heard the news?

Bionic to be acquired by CrowdStrike to provide the industry’s most comprehensive cloud security platform. Together, we are creating the industry-defining cloud security platform, fully integrated from code to runtime.