According to the most recent StackOverflow Developer Survey, JavaScript is the most popular programming language amongst professional developers (69,7%). Most modern apps use this frontend technology to dynamically load content from the backend based on the user behavior or other events.
This blog article will explain the differences between JavaScript (Single Page) and traditional (Multi Page) web applications. Afterwards, we will explain the specific difficulties of Single Page applications (SPAs) from a security perspective. Finally, we will address the challenges of automating security tests for SPAs.
Differences between Single Page and Multi Page applications
The core difference between Single Page (SPAs) and Multi Page applications (MPAs) is the behavior of the app after a user interaction (i.e. clicking or scrolling). SPAs are able to only reload specific parts of the app. MPAs always transmit a complete new page.
The more technical explanation is:
- MPAs: When Multi-Page Applications react to user input or must show new content, they request a replacement HTML page from the server. After receiving the information, the browser renders the new page, showing the reloaded page to the user.
- SPAs: AJAX (Asynchronous JavaScript and XML) permits JavaScript web applications to refresh solely a section of a page. When you interact with Single Page Applications, your browser posts ajax requests to the server. Rather than rendering a replacement page, the server will simply send you a part of the information. The SPA can then use that information to render specific elements of the page directly in your browser.
There are numerous articles about the Pros and Cons of SPAs vs. MPAs. Here are some links to articles we liked: MindK Blog (good explanation of core concepts and pro/cons with screenshots), Neoteric Post on Medium, Jaxenter Blog)
Interesting facts:
- It is commonly said that MPAs make up the largest share of web applications, but I could not find a trustworthy source for this information. If you have one, please comment below.
- Most modern webpages are developed as SPAs (i.e. Google, Facebook, Amazon, etc.)
- The most common frameworks for SPAs are Angular.js, react.js, and with some distance Vue.js and Ember.js (according to Google searches – Source)
Specific security challenges for JavaScript applications
JavaScript applications have some specific features that require specific security attention.
One attack vector commonly mentioned are Cross-Site-Scripting (XSS) attacks. There are multiple forms of XSS attacks, but they all exploit the possibility to inject malicious scripts in client / server communications in various ways (stored, reflected, or DOM-based). For a complete overview of XSS attacks, see our blog post.
Due to the separation of displaying content (frontend) and evaluating content (backend), SPAs can be more susceptible to XSS attacks. However, if you follow standard best practices guidelines (i.e. sanitizing user input and configuring security headers), these can be prevented.
The bigger challenge however, is the testing for security challenges in SPA applications.
Challenges of automating security tests for SPAs
Traditional security audits of web applications followed the HTML framework and commands to crawl the web application and identify potential attack vectors. For each HTML page, all the crawler needed to do was to scan the first page, test the attack vectors, then click on each link to get the next page, repeat until all pages are scanned.
For JavaScript applications, this is not possible. In SPAs, content can be generated dynamically when the user reaches the end of a page or certain features appear in pop-up or modal dialogues, which are only visible after a click.
This presents challenges for the automatic testing of dynamic web applications. Attack vectors can now be found in the frontend, the backend, and the communication of the two. Most security products these days require the user to manually create click sequences and specifying specific value entries for the discovery of attack vectors. This takes a lot of time and requires frequent changes to the security tool setup (i.e. when the software flow changes).
The setup of one specific attack vector could easily take 5 to 15 minutes. Imagine implementing this for 20 attack vectors – and the next deployment, the app logic changes. Another 2 hours to be invested.
This work is especially challenging when working in an agile development cycle with automated CI/CD processes.
Let us know in the comments if you have these challenges – or others – for testing your JavaScript applications.
Learn more about Crashtest Security and our upcoming launch that will address these issues on April 3rd on our launch page!
This blog post first appeared on the Crashtest Security Blog.