Building secure forms and getting data from those forms into usable formats has been a cornerstone of my development efforts for decades.
When I say get form data into usable formats, I mean the two main uses of forms are as lead generators or contact/support users.
Spammers see that differently with only one main use: deliver their junk payloads. That could be defacing a website, hacking into a database and stealing the data, or delivering marketing garbage to inboxes (ie, spam, porn, etc.). Preventing spammers from hijacking your forms is critically important.
Your choices for security include:
- Do nothing
- really not a practical solution. Best case is your website will get defaced and/or you will end up with tons of junk in your inbox. Worst case is hackers will steal your user data. - Use a validating technology based on the front-end (real-time) feedback to the user
- Pro: excellent to give feedback immediately and typically unobtrusive (and with more than 97.4% of websites using Javascript, it is well supported)
- Con: based on the user's own computing environment and can be easily manipulated - Use a validating technology based on the back-end (processing the form data on the server)
- Pro: can't be easily hacked or spammed
- Con: none that are obvious
One of the "cons" on using a front-end technology is that a hacker can easily defeat the validation by disabling the browser's scripting. That has been dramatically helped with HTML5 - now most modern browsers support validation as a built in function. While I don't want this article to degrade into a hacker's work book, HTML5 can also be easily bypassed. All the hacker has to do is write a small program to remove the form attributes for validation (ie. remove required, change input types, etc).
It's still valid though, since it will prevent all but the most intent hackers from hijacking your forms.
My product of choice is an "open source" tool called jQuery Validation Plugin. I've used many different Javascript and jQuery validation tools - this one is the best of the best. To be quite fair to all developers, this is NOT perfect. There are errors in the validation rules (methods), and quite a few rules (methods) that are missing. For examples, when validing URLs, there are many non URL strings that show as validated and many URLs that show as not validated. For example, if trying to validate the URL "test.com", the default behaviour of the plugin is to reject that. I've come up with work arounds to all the issues I found, and will share those in a separate artile.
One advantage of jQuery Validation Plugin is that it uses HTML5 validation notations. I really welcomed HTML5 validation, but I soon gave up on it as a first-line strategy. You can't add to the validation rules – well you can, but, not easily. You can add a pattern, and have it unique to that field. As a developer, though, that is not a good strategy. If you ever have to update the pattern, you have to manually edit every form you created. Despite that, HTML5 validation is still an option ... not first line. For example, when using jQuery Validation Plugin, the plugin automatically disabled HTML5 validation. That's good - you don't want to end up with two different technologies working on the same validation ... plus, jQuery Validation Plugin is far more robust, thorough, and customizable than HTML5 validation. And if Javascript is disabled on the user's browser, it automatically uses HTML5 validation instead.
Meaning, the best of two possible front-end technologies.
How to make it so that even if they hack, they can't get through? With server-side technology to validate the input. For server side validation, PHP is the winning scripting technology. Here again, I tried many different pre-built "open source" scripts. I ended up settling on an MIT licensed technology. I can't even recall the original name or original author. As good as it was, it lacked significantly in rules and methods. Over the years, I modified this script so significantly that the original is no longer recognizable. In the early days, I was forced to modify as I discovered validation "holes". After all the holes were blocked, I enhanced the rules and modernized for different languages. This FormValidator has not been hacked or bypassed by spammers/hackers in well over ten years.
My FormValidator has rules not found in other systems. For example, I block spammers from including links in most fields. For example, a URL does not belong in a name field. I also don't want URLs in messages. So, I have a rule called "nourl". It will block all the way to the simplest form of URLs like "test.com". Even if a user makes a mistake and forgets a space after a period, "nourl" catches it as a URL. Can a URL still get through? Well, yes, it can – but not as a clickable hyperlink. For example, a spammer could type in "test. com" (with a space after the period), but most email systems that make a URL clickable will not do it to that link. So, I can read parts, but it is not a pay load in a manner of speaking. Spammer defeated in my view.
My "rules" are patterns that work. And I have added all the popular and necessary rules for me. I live in Canada, and a Postal Code rule is necessary. So is a US/Canada phone number rule, a corrected Email rule is also a must. So is a proper US Zip code rule that handles 5 number zip codes, as well as 5-4 number zip codes. What surprised me the most is the lack of alpha and alpha numeric validation in jQuery Validation Plugin ... I've now added those as well as extended them to handle the basic A-Z characters AND Accented Characters.