Escape, sanitize, and validate to ensure clean code

WordPress has built-in functions to make it easy

Some code development is pretty independent of the user, such as displaying a template or a shortcode with baked-in content and structure. But sometimes the display is dependent on user input, whether that’s content they enter or just details about the user themselves. When this is the case, it’s crucial to make sure your code is secure. Whenever a user has the chance to input data, there’s a chance a bad actor will come through and attempt to manipulate your site for ill intent. Thankfully, WordPress has some recommended practices and built-in functions to help prevent these types of security issues from occurring.

Sanitizing User Input

In just about every case using WordPress, the actual data of your site is stored in the site database. Details about the user like email address, ID, name, and any short biography they choose to add all have their own table. As does every page and post, with the entirety of its content (pared down to its base HTML code). As a first step, you don’t want any bad actors to have the ability to store malicious scripts or other harmful code in the database. So if your code allows for user input, you need to sanitize it before saving it in the database for later.

In most cases, all you have to do is run the data through the proper cleaning function right before it’s sent away to the database. There’s a whole section of the WordPress codex about this, but some of the most common functions you’ll likely be using are:

• sanitize_text_field() which allows you to filter out any code tags from the saved data. This is ideal for something like the user’s name, where code is unnecessary anyway and you only want the words themselves to be stored.
• sanitize_textarea_field() does the same, except it allows for line breaks and a few other key differences between standard text fields and textarea fields.
• wp_filter_post_kses is a more complex function that takes more time and resources to run. It’s designed by the WordPress, and used in the native functionality to save post content, when the data that needs to be stored actually needs to have code and HTML tags. This function doesn’t strip out everything, but instead looks for “evil scripts” in particular and removes them from the data before it even hits the database.

Escaping Output from the Database

While sanitizing is a crucial security step, it’s not an absolute guarantee that no bad data will enter your database. Maybe a security issue is revealed that allows for a workaround, or maybe a bad actor gains direct access to your database without your knowledge. That’s why the next step, to escape any data from the database before displaying it, is just as crucial as the first.

Escaping does essentially the same thing as sanitizing, except it happens at the end of the process instead of the start. In fact, you want to escape at the last possible opportunity before displaying the data, to be sure it can’t be tampered with before it hits the user’s screen. Best practice dictates to sanitize early, escape late.

You can find more about escaping via the same WordPress codex page as sanitizing, that’s how closely linked they are. Some of the most common functions you’ll be using on variables right before displaying them are:

• esc_attr() is the equivalent to sanitize_text_field(), stripping out anything that’s not the actual typed words themselves.
• esc_textarea() is fairly self-explanatory, doing the same as esc_attr() but allowing for line breaks and other formatting differences provided by textareas.
• esc_url() a crucial difference here, which ensures URLs don’t become broken or malformed when displaying as well as not having any malicious data.
• While esc_html() does exist, the best practice for displaying full on code is to pass it through the content filter built into native WordPress. It will look something like this: apply_filters(‘the_content’, $data). This filter does a little more than just escape data, ensuring that whatever is being presented on the screen is safe and coherent.

Validating

Validating takes a bit more of a focused approach. Essentially, it’s making sure that the data you’re receiving is the right type of data that you actually want to be receiving. This is practices like ensuring the submitted phone number has the correct number of digits, the email has one and only one @ symbol, the username they claim to have actually exists, and so on. Those are just some basic examples, and there’s more nuance here than with sanitizing and escaping since it depends entirely on the nature of your project and what types of data you receive from inputs. There are functions that allow you to check how many objects are in an array, whether a URL or filepath is properly formatted, and even what a content string starts or ends with. But effective validating can save a lot of hassle down the road, throwing errors instead of allowing improper data into the database.

At Mr. WPress, we’ve had our own share of clients dealing with security issues, and we know just how important these security practices are. It’s peace of mind, knowing that your user inputs are safe from bad actors. And if the worst happens and something does go wrong, you can narrow down your search in finding out what happened.

Need a security review of your site or code, or just want a more experienced team to take on your next coding project? Don’t hesitate to reach out to us for a free quote! Code security is at the top of our priority list, and we’ll do everything we can to make your site solid and secure.