How to Build Secure WordPress Plugins?

WordPress is used by over 35% of all websites and 98% of WordPress vulnerabilities are related to plugins. So it is very important to know how to build secure WordPress plugins.

Writing WordPress extensions is pretty simple in terms of software complexity, even if you only understand the basics of PHP (a language WordPress has been built on).

With WordPress being the most popular CMS, the plugin repository is growing day-by-day and currently counting more than 40 thousand plugins.

Protect your websites from plugin and theme vulnerabilities

Try it free

All of the WordPress API functions can be found on WordPress.org Codex where besides explanation what particular function does, you can find the source code for better understanding.

One of the common mistakes is copying code snippets from various websites without understanding what it does “under the hood”. In this article, we put together some of the most common mistakes which lead to security issues in WordPress plugins and themes.

is_admin doesn’t check for the account type

Very often new WordPress developers are confusingly using functions that do not actually do what their name suggests.

As an example, `is_admin` function is often used with the intent of checking the permissions of the current user.

In fact, this function only checks whether the code is run from one of the administrative endpoints (wp-admin/*). Those endpoints don’t even check if a user is logged in or not.

Quotes are escaped by default

WordPress ajax hooks is generally a good place to look for vulnerabilities as they are exposed either to every visitor or only registered and logged in users.

All request parameters are by default escaping quotes. In case you want to get original content sent by the user in the request, use the `stripslashes` function, but be careful how that input is processed later in the code flow.

Use nonce correctly

“A nonce is a “number used once” to help protect URLs and forms from certain types of misuse, malicious or otherwise. WordPress nonces aren’t numbers but are a hash made up of numbers and letters. Nor are they used only once, but have a limited “lifetime” after which they expire.” – WordPress Codex

A nonce is used to prevent CSRF attacks. Therefore, each action should have its unique nonce code. Instead of creating nonce like:

wp_create_nonce( 'delete-post' );

Append ID of the object or some unique identifier: `wp_create_nonce( ‘delete-post-‘.$post->ID )`.  This way you can verify that request came from before performing any action on the object.

A nonce can be verified using the following function, which will return boolean (true/false) whether nonce is correct or not wp_verify_nonce( $_REQUEST['_nonce_name'], 'delete-post'); 

Source code analysis

Using static source code analyzers is not a very widespread practice in the WordPress developer community. However, using such tools can help you find bugs and bottlenecks much faster and easier and help you to secure WordPress plugins.

Some of the famous tools are Blackfire which can help you find performance issues in PHP applications and phpstan, PHP static analysis tool.

As we at WebARX pay attention to the security type of bugs in the code, we have decided to develop a source code analysis tool to provide bugs in WordPress extensions.

You can get it from GitHub OWASP/wpBullet

Learn more about securing WordPress plugins

Read more