Why Client-Side Validation Can Get You Hacked

Client-Side Validation Risks

• Client-side validation = fast checks in the browser for UX, not security.
• Attackers can bypass/modify client code to submit malicious inputs.
• Relying solely on it exposes apps to injection, logic bypass & data tampering.
• In the cases below, critical flaws stemmed from checks enforced only in the client.
• Best defense: enforce server-side checks (validation, authorization, state) and encode output for XSS.
• Combine with secure coding practices + regular testing for resilience.

Understanding Client-Side Validation and Security Concerns

Client-side validation is a widely used technique to provide real-time feedback and enhance the user experience. However, it is important to recognize the limitations and security risks associated with relying solely on client-side validation.

Malicious browser extensions are a related client-side risk; see Chrome extension security threats and risk analysis.

For a worked example of reflected XSS in an attribute context, see Reflected XSS in SVX Portal V.2.7A.

While client-side validation improves user experience by validating user input in real-time, it also introduces a significant vulnerability. Malicious actors can intercept and manipulate requests through proxies, as the validation process occurs within the user's browser. This manipulation can lead to security breaches and unauthorized access.

Client-side issues need a human in the browser, which is exactly what our web app penetration testing services provide. When comparing vendors, our guide to the top web application penetration testing companies shows what to look for.

Uncovering Weaknesses in Client-Side Validation

Account Takeover by Bypassing OTP on Password Reset

Understanding the Vulnerability

During a security assessment, our pentester discovered that the API response provided different outcomes based on the validity of the OTP. A correct OTP resulted in a "200 OK" status response, along with a JSON object indicating successful verification. In contrast, an incorrect OTP triggered a "401 Unauthorized" status response, indicating failed verification.

Exploiting the Vulnerability

Recognizing the potential impact of this vulnerability, our pentester set out to exploit it and gain unauthorized access to user accounts. By intercepting the password reset request and modifying the API response to indicate successful verification, the pentester bypassed the OTP validation process. This unauthorized access was possible due to the sole reliance on client-side checks for OTP validation.

Request:

POST /api/v1/reset-password HTTP/1.1
Host: example.com
Content-Type: application/json

{
"email": "attacker@example.com",
"otp": "123456",
"new_password": "newpassword"
}

Bypassing XSS Protections Resulting in Stored XSS

Understanding the Vulnerability

In the target application, users had the ability to change their usernames from the account settings page. Client-side validation using a regular expression (regex) was implemented to ensure that the usernames met certain criteria, such as length and disallowed characters like <>"'.

Exploiting the Vulnerability

Unfortunately, the vulnerability arose when the request reached the /api/v1/update endpoint, where no server-side validation was performed. This allowed an attacker to easily set a username to an XSS payload, such as newuser"><svg/onload=alert()>. The payload would then be saved in the database, and when other users interacted with the attacker's profile or viewed comments, the XSS payload executed, compromising the application's security.

Request:

POST /api/v1/update HTTP/1.1
Host: example.com
Content-Type: application/json

{
"username": "newuser\"><svg/onload=alert()>"
}

Payment Amount Manipulation

Understanding the Vulnerability

The web application in question served as a payments platform, enabling businesses to receive payments both in person and online. During the online payment process, businesses could create invoices for specific amounts and send payment links to their clients. Stores running a hosted checkout should also get Shopify penetration testing.

Exploiting the Vulnerability

During our pentesting process, our team discovered a critical mistake made by the client developers. Although they had implemented client-side validation to check user authentication and invoice information, they stored all payment-related data in a JavaScript variable. This variable was used for validation on the front-end before sending the payment request to the payment API.

By intercepting the request and modifying the price of the invoice, an attacker could exploit this vulnerability. As the server solely relied on client-side validation, it would update the payment data without verifying if it had been tampered with.

An attacker could pay a fraction of an invoice and have it recorded as paid in full, causing direct revenue loss and reconciliation errors. Further consequences could include undercutting competitors by making fraudulent payments, selling the vulnerability as a service to exploit other online markets, and damaging our client's business reputation by publicly disclosing the vulnerability.

Additional Scenarios

CSRF Attack by Bypassing Token Validation

Understanding the Vulnerability

The application utilized CSRF tokens to protect against cross-site request forgery (CSRF) attacks. These tokens were generated on the server-side and included in forms to validate the authenticity of subsequent requests.

Exploiting the Vulnerability

However, our pentester found that the server did not reject requests in which the CSRF token was missing or altered. An attacker could therefore host a page that submits a forged request without a valid token, and the victim's browser would send it with the victim's session, performing actions on their behalf.

Client-Side Injection of Unauthorized Data

Understanding the Vulnerability

The application allowed users to submit data that would be displayed on their public profiles. Client-side validation was implemented to prevent the submission of malicious content or unauthorized data.

Exploiting the Vulnerability

Our pentester found that the client-side validation could be bypassed by manipulating the request parameters. By injecting unauthorized data through the browser's developer tools or intercepting and modifying the request, an attacker could submit content that should have been restricted, such as scripts, sensitive information, or inappropriate material.

Fixing Client-Side Validation Vulnerabilities

To mitigate the risks associated with client-side validation, it is crucial to implement server-side validation. By shifting the validation logic from the client-side to the server-side, comprehensive checks can be performed, including authentication, data integrity, and authorization verification. This approach ensures that user input is thoroughly validated before further processing, reducing the potential for exploitation.

Server-side input validation is necessary but not sufficient on its own. For stored XSS, the primary defense is context-aware output encoding (escaping) wherever the value is rendered, plus sanitization of any HTML you allow; input validation and a Content Security Policy add defense in depth. For CSRF, validate the token on the server and reject any request where it is missing or invalid. For OTP-based password resets, verify the OTP on the server, require that verified state before accepting a new password, and rate-limit OTP attempts. For payments, validate the amount on the server against the stored invoice and ignore client-supplied prices.