Generally what you're doing is perfectly fine as long as you are filtering the input, and escaping the output. The hidden field method is valid and many many sites use it as a tactic to keep all the data in one place, but not necessarily in the users visibility range. The problem with that is that certain tools like Firebug in Firefox can actually alter the HTML so they can change those hidden values to be something that you're not expecting. Of course certain programs / extensions can change the actual headers and requests sent, but nothing can really protect against that type of change.
You're best bet is to limit the inputs, and make sure that you're getting what you expect in the format you expect. By limiting the input you're weeding out all those extra items that could cause you trouble and narrowing it down to a few things. For example, if they can only ever update / edit a few fields, just show them those few fields instead of the entire form (or display the rest of the form as static text (e.g. using <p> tags instead of inputs) and only have inputs for those items that user can really edit.
You could also use sessions, cookies, and hashes to help secure your code a little bit. Put a unique signature in a session variable, and add a cookie to the users browser which holds the data you want passed from form to form. Then when you're ready to read it in, check to see if the signature in the cookie matches that of the signature found in the session. It could work much like an md5 or crc32 check of the data.
I'm no expert in xss or security; however, if you limit what the user can really do, and always filter what they give you, there shouldn't be a problem.