A Guide to Writing Secure Themes – Part 1: Introduction

As a developer, keeping your users secure should be your most important priority.

Having a theme available on WordPress.org is a huge responsibility, because security issues make every site running the theme potentially vulnerable.

This guide will give you an introduction to the techniques you can apply to write secure code.

The guide is broken up into parts to make it easier to read and apply. It contains everything I learned over the past three years while reviewing themes for WordPress.org, premium themes for WordPress.com, as well as themes and plugins for WordPress.com VIP.

Before we get to the techniques, let’s have a look at the principles of secure code.

Principles of secure code

Writing secure code is not about using a particular function, tool, or workflow. Those things change over time, with new development techniques emerging and new security issues arising.

The common element that connects all these things together is the state of mind of the developer. This mindset is based on three principles:

  1. Don’t assume anything. Only act on what you know for sure.
  2. Don’t trust any data. Consider data invalid and insecure until proven valid and secure.
  3. Don’t become complacent. Web technologies evolve, and so do best practices.

With these principles on our mind, let’s clarify the meaning of a few terms we’re going to use in this series.

Commonly used terms

Input and output

When we talk about input, this designates all the data that is given to our code.

The most prevalent use case is information entered by the user, for example into a form field or the browser address bar. But it also encompasses data retrieved from stored cookies or from external services, like the Twitter API.

Themes deal with this data in various ways. They might store it into the database, use it to retrieve data from the database, or display it to the user.

When we talk about displaying information, we use the word output. But output is not just what we see on the screen, it’s all the data provided by our code.

Imagine a PHP script that passes data to a Javascript script, such as data used to initialize a slider for example. In this case, the PHP outputs the data that is then used as input by the Javascript.

If your code connects to a REST API, the JSON data returned by the API is the output, that your code then uses as input.

Dynamic and static data

When we talk about dynamic or static data, this is not to be confused with the static keyword in PHP.

When we talk about static data, we designate data that cannot be changed except by changing the code. Here is an example:

<?php echo 'Hello World'; ?>

So when you read static, think of static HTML pages. These documents cannot return information that is not present in their source code.

Dynamic data on the other hand can be modified through different ways. For example:

<?php echo __( 'Hello World', 'wptrt' ); ?>

In this code sample, the __() translation function returns data. This data can be filtered, or modified by loading a translation.

What we are outputting is the return value of the function. Let’s look at this in more detail.

Return values

Return values is data provided by a function. In PHP you often see these return statements in functions:

<?php
function wptrt_add_numbers( $a, $b ) {
    return $a + $b;
}
?>

Functions can return all kinds of data. Currently in PHP there is no way to force a function to return a certain type of data.

This is important to keep in mind, because a lot of WordPress functions contain filters. So you can never be sure about the data that a certain function returns.

Now that we have seen the vocabulary, we’ll look at common attacks.

Common attacks

In order for you to secure your code, you need to understand how attacks work.

A good starting point is to read through the list of the Top 10 attacks in 2013, published by the Open Web Application Security Project (OWASP).

Google Application security also has a very good introduction to Cross-Site scription (XSS) attacks. You actually can test out these attacks in the browser.

If you are interested in specific attacks for WordPress, I recommend reading the Sucuri Blog.

Conclusion

This part should have provided you with a good overview of what security is, the related terminology, and the type of attacks encountered.

In the next part, we’re going to look at how you can protect against some of these attacks by validating data before use.

#writing-secure-themes