The Client-Side Validation That Cost KSh 50,000

The situation

A financial institution had a loan calculator on their website. Customers could input loan amounts, review interest rates, and calculate repayments. The calculator was part of the customer experience.

I was reviewing the application as part of a security assessment. The site appeared well built. The design was clean. The user experience was smooth.

But something caught my attention. The validation logic for loan amounts was happening in the browser. When I opened the developer tools and looked at the JavaScript, the pattern was clear. The application was checking values on the client side and trusting those checks when sending data to the server.

That pattern is common. It is also dangerous.

The investigation

I tested the assumption. I opened the developer console, navigated to the checkout function, and examined the code. The application was accepting input from the browser without verifying it on the server.

I modified one line of JavaScript:

FROM: let productPrice = 299;
TO:   let productPrice = 0.01;

The value changed. The calculation changed. The request sent to the server reflected the modified value. The server accepted it.

A KSh 50,000 product could be purchased for KSh 0.

No brute force. No credential theft. No complex exploit. Just a browser, developer tools, and an assumption that the client was honest.

Why it mattered

The vulnerability was not in the code itself. The code was working exactly as written. The problem was the trust model. The application was designed to trust the browser.

This is a common architectural mistake. The browser is not a trusted environment. Anyone with access to the page can inspect, modify, and resend requests. Client-side validation is useful for user experience. It is not useful for security.

The business impact was clear. A malicious actor could manipulate loan amounts, interest calculations, or any other value that depended on client-side validation.

The fix

I reported the finding to the client with a clear explanation and a step by step remediation plan. The fix was straightforward: implement server-side validation for all financial calculations and prevent the server from accepting unverified client-side values.

The client implemented the fix within 48 hours.

What I learned

This incident reinforced a lesson that applies to almost every web application I test: never trust client-side validation.

The browser is not a security boundary. It is a user interface. Security must be enforced on the server, where the user cannot modify it.

This finding also highlighted a recurring pattern in the applications I review. The development team had focused on building a good user experience. They had not considered what happens when a user looks at the application from a different perspective. That is the gap I look for.

Technical takeaway

The investigation involved:

• Client-side JavaScript review
• Browser developer tools
• Request modification and resubmission
• Server response analysis

The lesson applies broadly to web applications and APIs: validate everything on the server. Trust nothing from the client.