After you’ve downloaded the code and put it on your server, you use it like so:

require('/path/to/EmailAddressValidator.php');
$emailValidator = new EmailAddressValidator();
if ($emailValidator->check_email_address('test@example.org')) {
    // Email address is technically valid.
} else {
    // Email not valid.
}

The second part of this analogy is that while it’s important for a restaurant to look clean (so people will eat there), it’s more important that it’s actually clean (so that diner’s don’t get sick, so that the inspector doesn’t shut you down, etc.). And so your Web site must actually be secure, so that nothing bad can happen to the users, your clients, the Easter bunny, and so forth.

The final reason I think this analogy works is that like security, like cleanliness, isn’t an absolute and the amount of effort you put into it should depend upon the situation. Your front porch doesn’t need to be that clean, but your bathrooms and kitchens sure do. And maybe you’re the kind of person that would thoroughly clean monthly, weekly, or daily. Maybe you’re the kind that will take cleaning to the disinfecting level. There’s no right answer in these situations: there’s better and there’s worse and there’s what’s right for you and your situation. The same goes for security. A site that handles no money has one level of security requirements; a site that performs online banking has a totally different level. Most importantly, just because you cleaned today, doesn’t mean your place will stay clean forever. And the Web site or application you ship today without any issues could become vulnerable tomorrow (most likely because of a found concern with underlying software or third-party applications).

So there’s my simple, yet overly-described, analogy for Web site or application security. Hopefully it’ll help you in the way you think about your Web site (or the next meal out!).

You really have to start thinking about security from the get-go, which means the database. Secondary column properties make a big difference to the reliability of the stored data. This means identifying columns as NOT NULL, UNSIGNED, a particular number of decimals, and applying a UNIQUE index (all of these as appropriate, of course). These settings will prevent bad data from getting into the database, such as negative quantities or duplicate email addresses (the PHP code will need to handle those MySQL rejections, though).

In your PHP code, you’ll want to use regular expressions to validate data when you can. And all strings should be run through an escaping function like mysqli_real_escape_string(), prior to using them in a database query. I would do this even if the data already passed a regular expression (you cannot be too careful). You can also consider applying strip_tags(), too.

For numeric values, I strongly recommend type-casting:

$something = (int) $_POST['something'];

Type-casting to numbers will make the data safe to use in queries. If you type-cast a string as an integer, the result will be zero, so you can type-cast, then check for a valid value (i.e., greater than zero). Valid numeric values will just be formally converted from a string with that value to a number with that value.

With variables, it’s also best to assume the values are invalid or not present at all, then prove otherwise.

When you get to your HTML, there’s not much you can do to guarantee security, but you can encourage it. For example, you can limit the length of a text input to whatever is the maximum size of the corresponding column in the database. Or you can use drop-down menus with preset values. Client-side validation using JavaScript is nice for the end user, but is not a real security tool as JavaScript can easily be disabled.

Once you’ve done all that (and hopefully you already are doing most of these things), you can run some tests to find potential security holes. To start, I think about the three kinds of people that use the site: those that use it perfectly, exactly as intended; those that use it without malicious intent, but that might cause problems; and those that are trying to hack the site. In the first category you have pretty much just me. I’m developing the site, I know what it’s supposed to do and how I think it’s to be used, and I’m not likely to break it. In the second category is almost everyone. They just want to use the site, they may make mistakes, they may have apostrophes in their names, and they just expect the site to work regardless. For these people, the goal is to provide a proper user interface, point out mistakes when they occur, and insure that clean, proper data is used at every step of the way. For the third category of user, they’ll do everything they can, include taking extraordinary steps, to try to break your site in order to get some information they deem useful.

There’s really no point in testing the site as I’d use it, so I quickly start imitating the behavior of the second group of users. First, I test my PHP scripts by submitting forms without doing anything at all. The result should be appropriate error messages to the end user, without ANY “undefined index” or similar PHP errors. The same goes for scripts that expect to receive values in the URL: test them without sending any values in the URL and see the result. Second, I fill out forms using invalid values: numbers for strings and vice versa. What is the result? Third, I fill out the forms using potentially valid, but complicated values, such as strings with apostrophes and quotation marks, possibly even with HTML.

As I said, I’m not maliciously-inclined (or I’d like to think I’m not), so it’s hard for me to think like a hacker. Much of what a hacker might try to do will be caught by the previous set of tests, though. If your site handles invalid data, apostrophes, quotation marks, and HTML tags properly, you’ve already done a lot to prevent bad things from happening. Hackers might take things further though, like creating their own HTML form that submits data to your PHP scripts (you can POST data without using a form at all, too). What if a hacker were to create a copy of your form, and replace your “quantity” or “states” drop-down menu with a text input, so they could use their own values? How well would the PHP script handle that contingency?

Hackers also like to get into places they shouldn’t, so try directly accessing scripts or directories that should be protected. Also try directly running scripts that are meant to be included, such as a configuration file. If you’re serving files to only authenticated users, can those files be viewed directly?

Sometimes the goal of a hacker is to find out information about your server, so you have to be extra careful that the site does not give too much away, specifically, too much about PHP, Apache (or whatever Web server), and MySQL. Towards that end, you have to make sure that MySQL errors are handled properly, without revealing anything to the end user. To do this, you may need to temporarily break your database scripts to see the result. For example, you’ve got a site working and it’s not giving away any secrets, whether or not the user behaves themselves. But what if the database server goes down or is to busy or something else happens to prevent your PHP scripts from connecting? What would the user see then? Hopefully nothing but a generic “system is done/come back later” apology.

With practice, developing sites to properly handle all of these situations and types of users becomes second-nature (not that you shouldn’t continue to test them). But I know that as you’re just getting going, it’s natural to feel like you haven’t done enough or tested enough. I hope that these few paragraphs provide a better feel for the process.

The most effective results came from using ROT13 encryption, in which the source code has the email address in an encrypted format, with JavaScript then dynamically creating a legible, and clickable, mailto link by decryption. Of course, the JavaScript method won’t work if JavaScript is disabled, but I don’t personally worry about that too much.

There are also two very interesting CSS techniques (this code comes from http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/):

<style type="text/css">
span.codedirection { unicode-bidi:bidi-override; direction: rtl; }
</style>
<p><span class="codedirection">moc.elpmaxe@emanym</span></p>

and

<style type=”text/css">
p span.displaynone { display:none; }
</style>
<p>myname@<span class=”displaynone”>null</span>example.com</p></p>

The first example says that the backwords HTML text should be displayed from right to left order. The second adds an invisible null to the example address. Unfortunately these two routes won’t allow for clickable links and make your site less accessible. Which leads me to a main consideration in this battle: There’s no perfect solution sometimes!

One option that I like is to just use a contact form that sends an email upon submission. This only really works if you have just a single email address associated with a site and it does limit what content can be sent (e.g., no attachments without some extra form work). On my own site, I use an image representation of an email address. But like the CSS methods, a link won’t be clickable and the accessibility is degraded. You can minimize the latter concern by making the ALT tag descriptive, like my first name plus my first initial at this domain. But also keep in mind it’s possible for bots to read images, which is why CAPTCHA text has to be so strange. That being said, I’ve been using this technique for a couple of years now and I don’t think I’ve gotten any spam on that address yet.

Those are relatively simple routes. If you want a really thorough solution, A List Apart has a detailed client- and server-side approach you can try.

As for what I’ve done lately, on a recent Web site I created, dozens of email addresses are listed for the different people involved with the project, so using a contact form wasn’t possible. The project itself involves people for whom accessibility is key, so the CSS techniques were out, too. In the end I went with a JavaScript solution, using jQuery and PHP, which the site is built with. This particular technique—and I have no hard data for how effictive it is—uses a PHP function to create a somewhat-obsfucated HTML source of an email address, then uses a jQuery Plugin to turn that source into a readable, and even clickable, link. For this project right now, it seems to be a reasonable compromise.

Of course, bots keep learning and they’ll figure out how to get around these techniques, which is why we all need to stay informed and try new things. That, and get rid of our email addresses every couple of years!

• Handling JSON Data Securely
• Debugging XML/JSON Requests
• Choosing a JavaScript Framework
• Performing Cross-Domain Ajax Requests
• Loading JavaScript Faster