It might be old news to some, but have you seen how easy it is for a (power) user to alter a web form so they can pass any field values they like back to the server!?
As an example, let's say you have a form with a computed field called Status on it. In edit mode the field's value is displayed to the user, like so:
Now let's look at how easy it is to turn this computed field in to an editable one. Assuming you have Firebug installed, right click the Draft message (or anywhere on the page for that matter) and select Inspect Element. You'll then be able to edit the HTML that forms the page, like so:
What if you edit the text and replace it with some HTML, like so:
Now look at the web page again; there's a field where the wasn't one before:
Imagine this happening in a workflow scenario where you'd expect the newly-submitted document to have a Status of "Awaiting Approval", but, as you can see above, they've managed to jump past approval and get it published straight away.
Now imagine it happening in a shopping cart scenario where you skipped the "Awaiting Payment" status and went straight to "Paid", which triggers the logic in the WQS event to mail out the merchandise. Hey, it could happen.
Even if no harm is done there's always the embarrassment factor and it never looks good if a solution you've sold a customer is "hackable".
What I can't work out is how to counter an attack like this. In a SQL-based environment, when a form is submitted you can use an Update() request to change the stored values of only certain "fields" -- the ones you'd expect to be "editable" by the user. In Domino there's no way to easily say "hang on, how come that fields changed?" or "Hey that shouldn't have changed, let's change it back to what it was. Hang on, what was it again?"
Any ideas on this one folks? Is it just a case of trusting your users either not to know how to or simply not wanting to hack you site?