Much of the web is made up of multi-page and single-page applications. Single page applications or SPAs are exploding in popularity because they perform a lot of real-time functionality such as updating content, facilitating personalization, and improving user experience. An important feature of single-page applications is performance. They get a performance boost by loading HTML, CSS, and JavaScript resources as soon as the website is loaded. However, they are not without their vulnerabilities. In this blog post, we explore single-page applications (SPA), the functionality they provide, and most importantly how to keep them secured by discovering and remediating high-risk vulnerabilities.
What are Single Page Applications?
Single-page applications are single pages on which most information remains constant, while smaller pieces of data update to match user intent. For example, when checking your emails in Gmail, the header and sidebar generally remain constant as you alter between your inbox, spam, and sent folders. In this way, single-page applications avoid sending unnecessary information to your browser and make load times much quicker. Examples of single-page applications include Netflix, PayPal, and Google Maps.
Top 3 Single Page Application Security Risks:
1. Cross-Site Scripting (XSS)
Using XSS, attackers can inject malicious client-side scripts into web applications. Single-page apps may be more susceptible to cross-site scripting (XSS) attacks than are multi-page applications, because of the greater reliance on client-side scripting for their functionality to manipulate user input. Although many frameworks include some XSS protection out of the box, there have been many instances of these being insufficient or misunderstood.
2. Data Exposure via API
SPAs typically present data to the client via an API. If developers do not place adequate authorisation checks on what data is returned in JSON/XML requests, as well as in the initial large page load, it is easy for sensitive data to be exposed to all users. A typical scenario is where an API relies on the client-side code to filter data intended for a particular user, which on the surface appears to be functioning correctly, in fact, means that any data may be accessed by any user, and possibly without authenticating at all.
3. Client-Side Logic & Client-Side Enforcement of Server-Side Security
There is a temptation in SPAs to use client-side logic almost exclusively in delivery of the goal of making minimal requests to the server-side API and delivering fast application responses. However, this can lead to missing access control at the functional level and a failure to enforce proper security server-side. Since developers move features and logic off the server and out to the client, it is easy to provide a client with access to functions that they should not be permitted to use. This is similar to the data exposure vulnerability outlined above, only relating to function access – for example a set of code for all functions may be returned and then a check made for if the user is an admin client-side before the SPA decides whether to display administrative functionality. However, if this check is not paired with appropriate server-side checks, then a malicious user with sufficient technical ability can “unmask” the administrative functionality client-side and gain access to functions that they should not be permitted to.
API Testing
Resources located on the server and loaded by the SPA are typically made available by an Application Programming Interface or API. These are notoriously tricky to scan because they cannot be crawled – instead, they consist of a number of methods, each of which takes specific parameters in order to return any valid data. A scanning engine cannot scan the server-side API accompanying a SPA without gaining specific knowledge of the API methods, as well as (typically) successfully authenticating against the API. This information must be either pre-seeded in the scanner, or else the scanner must be able to piece it together by simulating a client-side application by rendering and executing the SPA natively as a browser would and flexing the functionality by simulating a user action.
CheckScan+ Dynamic Application Security Testing (DAST)
Unlike many Web Application Security tools available, CheckScan+ Managed Application Security Testing service delivers web-based crawling techniques along with using a known signature-based approach.
By authenticating with the application and the associated API endpoints, the scanning technology, powered through AppCheck, has the ability to scan and crawl for high-risk vulnerabilities throughout complex and sophisticated workflows. This returns an accurate and comprehensive vulnerability breakdown of the entire attack surface including API endpoints and back-end technology.
These scan results are then individually analysed by our team of security experts and a process of manual validation is performed. By doing this, our customers are issued with clean and actionable vulnerability reports which are virtually false positive free, saving on time and internal resource restrictions.
Single Page Application Scanner
CheckScan+ helps you with providing assurance that regular vulnerability scans are being executed and how to remediate vulnerabilities across your web applications and network. We perform comprehensive checks for a massive range of web application vulnerabilities to detect security weaknesses within in-house applications also. Checkscan+ also draws on checks for known infrastructure vulnerabilities in vendor devices and third-party applications. Our vulnerability analysis engine provides a detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
Book a consultation with our Team.