RIA security concerns when using Google Web Toolkit

by John Tibbetts, Senior Consultant

Last week’s webinar “Web 2.0 and Rich Internet Applications” discussed the characteristics of various development approaches for building new-style, “live look-and-feel” web apps using Ajax, Flex or Google Web Toolkit (GWT). In particular we discussed how GWT alone among these alternatives provides a “single system image” to the developer, allowing him or her to use the same language on both client and server. It is an advantage for the designer to perceive a single application rather than two distinct applications joined with a pipe.

This observation drew an astute question from one of listeners. This question came in after the Q & A was completed (there were a lot of questions!). The question and its answer deserve consideration so I thought I would post it here.

****Roque Scherr writes****
My concern was about security. When you blur the separation between client and server code like GWT does you do not have a clear border between trusted (server) and non-trusted code (anything running at the client side). If developers are not well aware of that they may code security and data integrity verifications that would end being run on the client side, where they can be easily bypassed or intercepted. How are those issues addressed in GWT?

****John comments***

Roque, this is a great question. But my warning is: the topic is so rich I can do little more than sketch a response as a series of assertions. It really deserves a much fuller treatment.

Assertions:
Newer technologies make the distribution seam almost disappear, but it’s crucial that architects acknowledge the existence of this seam and create infrastructure to support a secure and performant environment.

For many years now I’ve been advocating that architects do a ‘trust analysis’ on their architectures. A basic principle here is that client platforms (unless they’re locked up in a safe with their users) are always considered untrusted. The servers are presumed to be trusted…sometimes they are. :~}

The “trust line” usually falls at the front-end of the server or even better in some middle-tier.
In my view, middle-tier platforms are pretty anemic in most “3-tier architectures,” but I advocate giving more attention to this middle-tier, with one of its major responsibilities being maintaining the trust line. (See our open-source middle-tier platform at the WorkThru) site.

Since the client is untrusted so should its messages be. A message from a client should be considered a “proposed unit-of-work” only. (Corrolary: *always* treat client validations as an end-user convenience only. *Always* repeat client validations on the trusted platform (nice middle-tier responsibility)).

Put your client security focus on a performant authentication method between client and server. People tend to move into RIAs continuing to use their Web 1.0 authentication machinery (e.g. SiteMinder). Problem is that the fractional-second delay per message, while okay at a web page boundary, can hurt badly if you’re doing many quick short Ajax-style trips. Better to use some cheaper, more adhoc authentication machinery between the client and middle-tier. This is quite doable because of the programmability of the client.

These considerations teach us yet again: Architects are needed in RIA projects!