To master WordPress, you have to be able to look at it from unusual perspectives. It’s exploring these perspectives that gives you that next level understanding. You’re able to view problems from another angle. This can give you unique insights that affect how you approach problems and design solutions for WordPress.
The angle we’re going to explore in this article is the concept of the entry point. Let’s take a look at how WordPress handles it.
What is an entry point?
The entry point is the piece of code that controls the entry to a program or a larger piece of code. It could be a function. It could be a file that’s read from top to bottom.
Each language has its own take on the concept of the entry point. In PHP, the entry point is always the first file that the web server accesses. It reads it from top to bottom and executed in that order.
The web server configuration determines the PHP entry point. You could limit to a single file or it could be any file accessed directly. That flexibility is also a weakness when you’re trying to secure a PHP application.
In the context of WordPress, an entry point is a PHP file that initiates the loading of WordPress. WordPress has a surprising amount of entry points. A lot of them exist to handle specific tasks which you’ll see later.
It’s all about security
WordPress entry points are a potential security vulnerability. Some entry point vulnerabilities are with PHP and your web server configuration. That’s why a lot of WordPress hardening recommendations are about securing the files on your server. You want to make sure that you limit the access to WordPress files.
Some WordPress security issues are deliberate attempts to abuse these entry points and your lack of understanding about them. Hackers can use them for brute-force attacks like the ones you see on “wp-login.php” or “xmlrpc.php”. These attacks are attempts to gain access to your admin console.
WordPress entry points are also vulnerable to denial-of-service attacks. Each individual entry point is vulnerable to those attacks.
A lot of these issues come from a simple lack of knowledge. It’s not that WordPress itself isn’t secure. It’s that you can’t take extra steps to secure what you don’t know about.
Going over entry points
The goal here isn’t to bore you with an extensive list of entry points. You can find most of them by searching WordPress for files that require “wp-load.php” or “admin.php”. Those are the bootstrap files for the frontend and the admin of WordPress.
There’s some exceptions to that rule like “xmlrpc.php”. That said, you’ll get a good overview using those two search parameters.
The default entry points
The default entry points to WordPress are the “index.php” files. This isn’t by accident. The WordPress server configuration says that the default file for PHP to process is “index.php”. Your server uses that default file when it doesn’t receive a request for a file. It doesn’t have to be a PHP file. It could be any file.
So let’s say you’re requesting “/wp-admin”. Your browser address bar isn’t pointing to a file. That means you’re using “index.php” in the “wp-admin” folder as the entry point. Simple as that.
“index.php” files are powerful for that reason. That’s why it’s always a good idea to put an empty “index.php” file in your plugins. You can leave it empty or add the well known “Silence is golden.” inside.
Task based entry points
WordPress uses a lot of entry points for tasks. That’s where it gets a bit hairy. There’s a lot of tasks and each has its own entry point. That’s why listing them isn’t useful to you.
What’s more interesting is the types of tasks that these entry points take care of.
Cron
Good old WordPress cron… The internet contains countless threads of WordPress cron not running, missed schedule errors and other issues. The goal was to offer a way to schedule jobs for installations that couldn’t control the cron jobs on their server.
WordPress implements cron using a custom entry point. Whenever someone loads a page, WordPress will send an asynchronous request to “wp-cron.php”. “wp-cron.php” checks for scheduled cron jobs and runs them.
The issue is that you need someone to visit your site for WordPress cron to run. This isn’t consistent. That’s where understanding that entry point interaction was useful.
The solution to the issue was to create a server level cron job to run “wp-cron.php”. This guaranteed that WordPress cron jobs would run at a regular interval.
Using the Upgrade API
Upgrade API you say? WordPress has an API for dealing with installing and upgrading WordPress. It’s found in the “wp-admin/includes/upgrade.php”. The API contains functions like “wp_install” for installing a WordPress blog.
It also has useful helper functions for interacting with the MySQL database. One of them is “dbDelta”. You use it when you want to maintain a database table with your plugin.
The API isn’t loaded by default. Only special entry points that deal with installing and upgrading WordPress use it. That includes the network install as well.
Admin pages
Each WordPress admin page is an entry point. There’s over 70 of admin pages in WordPress if you include all the network ones. That makes for a ridiculous amount of entry points.
Why are each of them an entry point? That’s a question I wasn’t able to find an answer to. There’s an API for administration menus. WordPress core doesn’t seem to use it though.
Regardless, this is why it’s important to take extra care to secure “/wp-admin”. Compromising any of these files would compromise your WordPress installation.
External interactions
There’s entry points dedicated to communicating with WordPress. These include systems like:
- XML-RPC
- Post via Email
- Trackbacks
- AJAX
- Commenting
The noteworthy one is XML-RPC. It’s used by almost every app or service that interacts with WordPress. The unique issue with it is that you need to log into WordPress for each call made to the XML-RPC API. There’s no cookie that WordPress can use to keep you authenticated.
So for every command, your username and password is sent in plain text to your WordPress site. That makes you vulnerable to man-in-the-middle attacks. That’s unless you use a SSL certificate on your WordPress site.
Authentication layer
WordPress uses a few entry points for its authentication layer. The most known is “wp-login.php” which is the WordPress login page. There’s also “wp-activate.php” and “wp-signup.php” when you enable user registration.
These entry points (“wp-login.php” usually) are often the target of brute-force attacks. That’s why there’s a lot of plugins to deal with this issue. You can also protect “wp-login.php” at the web server level to help with the issue.
Another way to look at WordPress security
It’s often misunderstood how WordPress security works. You follow a list of recommendations and don’t twice about it. Looking at WordPress entry points can help you make sense of some of these recommendations.
It’s all about that other angle. Sometimes looking at things from another angle can give you the understanding you need.