Sacrifice server validation in pos of performance with Rich Client validation?

Question

I recently started to work in a java enterprise project (~200 people) that uses a SWT rich client. In many cases I've found business rules not being validated in server side, because the widgets that trigger such actions are disabled in the SWT client using the business rules.

This is a well known question of validation in server, client or server+client and I'm not pointing to the same issue. Also, I'm in favor of validation in server+client.

The need of validation in the client is obvious because allows a more responsive application for the end user and less requests for the server.

The need of validation in the server is obvious with a web client, where one can play with the html and javascript for avoid the client-side validations and send incorrect data to the server.

But, with a SWT client this is not that simple (could be achieved with a package sniffer like Wireshark?) so one could argue that validate in the server would have an innecesary cost in performance. Always in a scenario where there is only one point of access to the application and it's the SWT client.

If the project had begun yesterday I would fight for server+client validation, but in a project with 8 years of history this could be difficult because we would have to convince end-users and analysts for the advantages of the performance penalty.

So, every time I find one of this validation holes I struggle between add the server side validation or let it go, thinking "the client will catch it and this will never happen" and continue with a more priority task.

This project has been productive four years, so it's a viable practice, but from the point of view of design, is correct this approach? Aniway I think this is a consequence and not something deliberately sought.

Could be taken it like a political decision with knowledge of the consequences or the software world will say NO to this practice?

Answer 1

Consider two options.

1. Validate everything on the server, at all times. Suppose you pay for 2 extra weeks of developer time (e.g. $10k), and e.g. $100/mo extra for more computing power. Nothing interesting happens.

2. Do not validate input and save the money and time. Then someone mischievous steals a secret, finds out that the server side allows to do anything, and wreaks havoc costing you $N. To prevent this in the future, you belatedly implement option 1.

If $N is sufficiently small, it may be rational to go with option 2. But I greatly doubt that for a project that hires ~200 developers this might be true.

Answer 2

I'd say no, its not. The reason is that anyone can sniff the network traffic to see what your calls are, and if you're not validating, you're opening up security risks as well as data corruption risks.

The performance rationalization doesn't hold water; are there performance issues on the client running the rules? If not, then there should not be running the same rules on the server either. Have you even tried to implement validation on the server to see what the performance penalty would be? From your question is sounds like the answer there would be no, and that the performance concerns are an after the fact reason not to do it.

It does not matter if this is an internal only application either; you're relying on your company's firewall to keep intruders out, but the problem is that firewall might fail to do so. Your apps need to be secure as well; this is known as depth of defense. You cannot rely on any one system for your security.

If you want to justify it, simply sniff one of the calls from the client to the server in something like Wireshark or Fiddler, alter it, say, make the price zero, or change some data to otherwise be invalid such that it cause the company losses, and then fire off that request (against a test environment, of course). If that doesn't convince them, I don't know what will.

Answer 3

As you pointed out, it's best to do validation both client side and server side. You want the client side validation so you can quickly give feedback to the user, and you want it server side because often the people who write the server code aren't the same people who write the client code and it's necessary to check assumptions.

However, the code has been running in production for 4 years without obvious problems. If the missing server validations were added (probably at considerable expense), the code would still run without obvious problems.

Unfortunately, the ROI on fixing this is likely almost zero.

If you add the server validation code in now, you have to consider the cost of ensuring it is doing exactly the same checks as the client side code (including any bugs in the client code).

The big value in server side checks in this scenario (rich client) is during development -- not after the system is in production, stable, and relatively bugless.