I recently wrote a feature article for eHealthcare Strategy & Trends magazine entitled, "How secure are your Web-based forms?" The article explored what happens after you press the submit button.

It turns out that lots of things can happen - many of them bad.

To clarify, "bad" is the wrong word. "Potential security weaknesses" is a better description. Once the information is whisked away it can be - and probably is - transmitted and stored in clear text.

To be fair, form security is not always needed. Take, for example, our website. Probably not a lot of sensitive or private information you'll be entering on a Web development firm Contact Us form.

But what about health sites, or banking sites, or ecommerce sites? In the context of these three types of sites, form security becomes quite important. It is these three reasons why we've been providing a continuum of form security which includes submission, notification and storage.

Submission is easy. It is handled by the ubiquitous SSL certificate. This encrypts information between the submitter and the Web site server. Cheap and reliable.

Notification (by which I mean how you learn a submission has been received on your site) gets a little trickier. The easiest way is for the Web server to dump the entirety of the form information into an email and send it to a staff member. This causes the form information to be sent in plain text, possibly touching several mail serving computers along the way. Then it arrives in someone's inbox and is stored in the mailbox of that user for who knows how long. All the time in plain text and visible to a host of machines and individuals.

A better way would be to simply notify of a form submission and provide a link back to the Web server to view it. That requires a login and password to view and, because you're viewing through the Web, it can be secured with that cheap and reliable SSL certificate.

To provide that notification, you need to store the form information in a database on the Web server. By default, database information is stored in clear text. As the final aspect of form security, we encrypt sensitive fields. This prevents someone from viewing these fields in the unlikely event that the database itself is compromised.

On Web sites, content has long been king. With Web forms, context is the real king. Every form must be examined for the possibility of drawing out sensitive information. This is true for something as innocuous as a general contact form. If that contact form is on a hospital or bank Web site, it may draw sensitive information from users - even if they are cautioned against providing it.

Updated: September 28, 2021 for link rot