RIAs are also different from traditional Web applications in that a significant amount of application processing can take place on the client machine, which is the source of the RIAs' performance improvements over traditional Web applications. RIAs are faster because much of their code is executed directly on the user's machine. This is a dramatic difference from the early days of the Web when browsers basically behaved like dumb terminals. Their only real purpose was to accept user input, send it to the server, and display the response. Back then, all the real logic processing took place on the server. Now, however, the capabilities of the Web browser have greatly expanded.
However, this begs the question: Just because you can push logic to the client, does that mean you should? Processing code on the server eats up performance time; also, network bandwidth is required to accept the request and to send the response. If all of this logic could be handled by the client, then the server would be faster and more scalable. But there is one serious problem with this approach: security.
Code that runs on the client tier is beyond the control of the developers and other teams within the organization who own the code. An attacker can attach one of the many, freely downloadable, debugging utilities to the RIAs component that exists in the Web browser and infiltrate the source code of the application as it executes. Any secrets in the client code will be plainly visible.
There was a recent case in which a high-profile computer conference's discount code was discovered embedded in the registration application. Unfortunately, the logic for checking and applying the discount code was implemented on the client. Before long, hackers found and used the secret code leaving conference organizers wondering how so many people were getting discounted passes to the show.
Even worse, attackers can use these same debugging tools to change the client-side logic entirely. Code statements can be executed out of order (e.g., first transfer the funds, then check authorization) or skipped entirely (e.g., just transfer the funds). Variable values can be altered (e.g., instead of a 50 percent discount, give a 100 percent discount). Input limitations can be removed (e.g., the phone number field will now accept values sixteen megabytes long). Again, code that is executed on the client is outside the control of its owners. There is simply no way to ensure that the code is executed as it was intended, or even that it is executed at all.
It is clear that, as tempting as it is from a performance standpoint, executing