DE

JavaScript Apps: Automated Security Testing Challenges

In this article:

According to the most recent StackOverflow Developer Survey, JavaScript is the most popular programming language among professional developers (69,7%). Most modern apps use this frontend technology to load content dynamically based on user behavior or other events.

This blog article will explain the differences between JavaScript (Single Page) and traditional (Multi-Page) web applications. Afterward, 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 can only reload specific parts of the app. On the other hand, MPAs continuously transmit an entirely 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 user’s reloaded page.
  • SPAs: AJAX (Asynchronous JavaScript and XML) permits JavaScript web applications to refresh a page section solely. When you interact with Single Page Applications, your browser posts ajax requests to the server; rather than rendering a replacement page, the server will 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: Andrej Gajdos Blog (good explanation of core concepts and pros/cons with screenshots), MindK Blog, Neoteric Post on Medium, Devmio 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 web pages are developed as SPAs (i.e., Google, Facebook, Amazon, etc. – see Andrej Gajdos’s Blog for more examples and gifs)
  • 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)

When did you last check your JavaScript app security level?

Specific security challenges for JavaScript applications

JavaScript vulnerabilities in applications have some particular features that require specific security attention.

One attack vector commonly mentioned is Cross-Site-Scripting (XSS) attacks. There are multiple forms of XSS attacks, but they all exploit the possibility of injecting malicious scripts in client/server communications in various ways (stored, reflected, or DOM-based).

Due to the separation of displaying content (frontend) and evaluating content (backend), SPAs can be more susceptible to XSS attacks. However, these can be prevented if you follow standard best practices guidelines (i.e., sanitizing user input and configuring security headers).

The more significant challenge, however, is the testing for security challenges in SPA applications.

JavaScript Vulnerabilities Prevention Guide

Prevention Guide

JavaScript Vulnerability Prevention Guide

Learn how to detect and prevent JavaScript Vulnerabilities and secure your web assets.

Download

Challenges of automating security tests for SPAs

Traditional security audits followed the HTML framework and commands to crawl the web application and identify potential attack vectors. All the crawler needed to do for each HTML page was scan the first page, test the attack vectors, click on each link to get to the next page, and repeat until all pages were 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, 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, backend, and communication of the two. These days, most security products require the user to manually create click sequences and specify specific value entries to discover attack vectors. This takes a lot of time and requires frequent changes to the security tool setup (i.e., when the software changes).

One specific attack vector setup could easily take 5 to 15 minutes. Imagine implementing this for 20 attack vectors – and the subsequent deployment, the app logic changes. Another 2 hours are to be invested.

This work is especially challenging 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.

If you want to learn more about other DevSecOps topics, integrations, or continuous security in general, visit our other content.

Get a quick security audit of your website for free now

We are analyzing https://example.com
Scanning target https://example.com
Scan status: In progress
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Date: 06/12/2022
Crashtest Security Suite will be checking for:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Complete your scan request
Please fill in your details receive the
quick security audit by email.
Security specialist is analyzing your scan report.
То verify your identity please provide your phone/mobile:
Thank you.
We have received your request.
As soon as your security audit is ready, we will notify you.