Why client-side XForms is not enough
About 10 years after the first version of HTML the W3C felt is was about time to create a sucessor of the HTML forms. XForms as a new open standard was born. Back then it was not surprising that XForms was emphasized to be a client-side technology which was expected to be built into the browser just like HTML forms are (this attitude changed later during the further evolution of this standard ). But XForms is not comparable to HTML forms in many ways. While HTML forms only provided some controls XForms offers a complete processing model with an MVC architecture, events, actions and a submission module and more. Without going into the details about these differences this article focusses on one aspect which is surely a prominent one for a forms framework: validation.
While some garbage data may not be a problem for a guestbook they are for a serious web application. XForms as the new standard in this area comes to the rescue. It offers a declarative way to put fine-grained constraints on data and even define dependencies between different data items. Now XForms is not natively supported in a single browser on this planet. No problem as there are several good client-side implementations around to fill that gap. So choose one of them, define your constraints and the problem is solved.
But stop – wasn’t there something?
“Never Rely on Client-Side Data Validation
Client-side validation can always be bypassed.
Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.”
This seems to be exactly the argument that the opposers of XForms always proclaimed: as long as XForms is not natively supported by all major browsers it will never gain importance for web application development. But that’s a fake argument. Even if browsers would support XForms natively this would probably make it harder to build an attack but you can still setup a page that sends manipulated data to the submission target. So OWASP seems to be right: ‘never rely on client-side data validation’.
How to get out of this dilemma? Is XForms altogether a bad idea? The answer is definitely no. XForms provides exactly the functionality that is needed to build reliable, flexible and future-proof applications today. It will be there for years while proprietary solutions come and go at will of their vendors. And the problem does not only apply to XForms but to any client-side technology used for data entry.
So only use server-side implementations and avoid the problem? That can be an answer and in fact those implementations have proven in many projects that server-side XForms is a real option. But server-side implementations are harder to setup and handle as the client-side ones. This raises the entry hurdles for many people. Further client-side implementations can be more responsive in some cases as they avoid roundtrips to the server that are otherwise mandatory for a full support of the XForms processing model.
How can this gap be overcome? We can go for a client-side XForms processor and replicate all validations on the server. This would of course take away much of the beauty of the declarative validation model of XForms as it forces to re-implement all validations on the server-side. And as XForms validation is so powerful it might even become a tedious, repetitive and sometimes hard to solve task. A lot of the productivity gain of XForms compared to hand-crafted script solutions would be taken away.
But the solution can be easier and more elegant. As XForms is an open standard all implementations should be interoperable meaning that the validation in one processor will lead to the same results as those from another. They are interchangeable. If we need double validation to really build secure web applications why not use a client-side processor to gather and validate the data and then send those data to a server-side processor for re-validation? All that would be needed is a reference to the original form document and the instance(s) in question. The server-side processor can then initialize the form with those instance(s) (which will include validation of the data) and forward the data to its intended URI. Or if something goes wrong send a response to the client that reports the problems found. The server-side processor would never create a UI or fire initialization events nor would it trigger any of the submission event handlers. Instead it would just forward the data or create a generic XML structure describing the validation errors.
However to make this idea a reality there are still some steps to take. An interface for the processor communication needs to be defined as well as a protocol for reporting and handling the errors. Ideally this protocol would become a part of the XForms standard itself. On the other hand XForms already has a powerful submission module that could be extended to address the described problem. E.g. a specialized URI scheme or additional property for the XForms submission element would allow to use a server-side processor to act as a proxy for a submission target.
Handling errors is a bit more complex and involves to develop a generic error-reporting structure (ideally expressed in XML) that can be interpreted by the client-side processor and results in alerts popping up or a general message explaining why submission has failed. As XForms is not most often not the only technology used to build a site or web application the using applications can also profit from such a generic error reporting by integrating it into their error page templates in cases where there is not a simple validation problem but a fatal condition that prevents a successful submission.
XForms is an open and device-independent standard and as such there will be hardly one implementation fitting all use cases and scenarios. But bridging the gaps between different implementations and let them act as one can underline the fact that open standards can accomplish much more than any proprietary solution will ever can.