WordPress Application Security – Part 1

wpsecureThis is the second article in our series “WordPress as an Application Frame Work“.

High Profile Security Problems

In light of the series of recent high profile web site security problems, it is clear that a web application developer should plan application security from the beginning.  The very features that make WordPress attractive to publishers and application developers also make it an attractive target for attackers.

In the first article of this series, we introduced the idea of WordPress as an application frame work for developing web apps.

According to a recent Information Week Article, “70% of WordPress sites are running outdated software and are vulnerable to hackers launching DDoS attacks. Recent examples hit MIT, NEA and Penn State servers.”

These numbers are somewhat disturbing. Doing some quick calculations…in May of 2012, Netcraft estimated that there were over 660 million web sites. If 20% of the web is running WordPress and 70% of those are vulnerable, that means 14% of the web, that’s nearly 100 million web sites, have known vulnerabilities.

Clearly we DO NOT want our applications to be in that number.  Any application framework would need to be strong in the fundamentals of the classic CIA Application Security Triad – Confidentiality, Integrity and Availability. What follows are some ways using  WordPress as an application frame work can make your application more secure using that triad as a framework.


Privacy has become a fundamental problem in our connected world, and it’s only going to become more important as more applications move to and are created for the web.  By design, an application must show information only to those who should see it.  One thing that makes WordPress a good application framework is its built in support for confidentiality.

Private vs. Public

WordPress has two “faces” out of the box: a “public face” and a “private face“.  The public face is what most people think of when they think of a web site.   The private face or back-end is where you add articles, posts, pages etc. It also contains a place for profiles and other administrative functions.  In order to have private access, you must log in. The WordPress settings let you determine who can get in, and how they are registered.

Roles and Capabilities

As a publishing platform, WordPress has the following roles built in: Administrator, Editor, Author, Contributor and Subscriber, each with fewer privileges than the previous.  But it has an expandable Roles and Capabilities system.  That means you are not limited to those roles at all.

Most developers realize that, when designing, it’s important to define a system’s user types. The WP Roles system is perfect for that.  Depending on the nature of your applications, you can use the roles and capabilities functions yourself to create precise roles and capabilities for your app, or you could use one of the many plugins that use the roles and capabilities system.

  • Eyes Only: User Access Shortcode – A very nice little plugin that allows you to limit any portion of nearly any content based on any or all built in WordPress access criteria:  by logged in status, by username, by role, or by capability.
  • Members by Justin Tadlock – A straight forward basic, powerful membership and role and capability management system. It’s stable and easy to understand. If you define your user types during your design phases well, you should be able to use this plugin to map them to WordPress roles quite easily. Between this plugin and “Eyes Only: User Access” shortcode you can pretty much protect any page, post, paragraph, or page section that you need to.
  • Capability Manager Enhanced – This tool lets you create and fine-tune precisely what users can or cannot do, ensuring an easy method to design for proper confidentiality.

It is common for any given data packet to go through a half-dozen or so servers between your WordPress server and the users’ browsers. HTTPS encrypts the transmission of data between your server and the browser, maintaining confidentiality.

If you intend for all interaction between your web app and your authorized users to be truly confidential, you should begin by having a valid SSL certificate installed on your WordPress server.  Next, you should insure that both  the login screen and the admin control panel of your web site is forced to use SSL.  To do that, you need to modify your  wp-config.php file by adding the following lines:

Additionally, you should be certain that when you setup your WordPress and Site URLS in the Settings / General screen, the your protocol is https. (i.e. https://example.com/myapp)

Authorizing Users

There are two ways to authorize users of your applications, manually or automatically.  If you have a relatively small user base, or your web application is an intranet application, you may want to manually authorize all your users by being sure “Anyone Can Register” is unchecked on the Settings/General screen.

If you are monetizing your web app by selling access to your web app, you want a lot of users.  If you have a lot of users, you will probably want to automatically provide appropriate access to specific functionality of your app based on user payment, this will be touched on in Monetizing Your WordPress Application.

 Integrity and Availability

We will discuss the next two legs of the CIA Triad – Integrity and Availabilityin the next article.


 (Image Credit)

Leave A Comment?

You must be logged in to post a comment.