As developers, one of the most important things we can do is prevent direct access to your plugin. By this, I mean if someone gets clever and tries to access to one of the files located in any given plugin’s directory, they should not be able to execute any of the code in the script.

Prevent Direct Access To Your Plugin

A simple plugin’s directory from which the below source is pulled.

And I know: This seems like something that’s easy (it is), but even in a recent project, I’m reminded how it’s not something that even some of the most useful plugins do.

I can only chalk this up to lack of awareness or perhaps lack of education. If you’re not setting your work up to prevent direct plugin access to your plugin, you’re leaving a significant security gap in place, and it’s something that can be easily corrected.

Prevent Direct Access To Your Plugin

Before showing the code for how to do this, I want to make sure it’s clear as to why we don’t have people to have direct access to our plugin’s code:

In short, if they can gain access to the scripts, then it’s possible they can execute certain parts of the code that are either outside of the WordPress API or that don’t necessarily do a job of checking if a user has permission to execute a piece of code.

Once they achieve this, the entire site can be compromised. Scary, I know. But no sweat. Making sure that a malicious user can’t gain access to the main plugin file of your plugin is as easy as making sure the first lines of your plugin (below the plugin header) look like this:

There are other precautions to make, as well.

  • You can set permissions to prevent people from viewing the contents of any given directory at the server level.
  • You can place an index.php file in the root of every directory (that will result in a white screen if they attempt to browse a directory.
  • You can make sure that the rest of your functions properly check for nonce values, if a user has permission to execute code, or if the user is even logged into WordPress before executing code.

This is not meant to be a comprehensive post. Far from it.

Instead, it’s meant to be an easy way to prevent people from executing a plugin by running the primary point of entry for many plugins that are running alongside WordPress.

Feel free to share your tips in the comments as this is something that I think is useful for any WordPress developer.

Category:
Articles
Tags:

Join the conversation! 6 Comments

  1. Very basic, but really essential tips. I check ABSPATH instead of WPINC, same thing though :)

  2. Does this truly add security though?

    I can think of two scenarios in which your file would be accessed:

    File is accessed directly in an attempt to execute some malicious code against some logic your code performs

    Yes, having a constant check would ensure it doesn’t execute; simultaneously cluttering up all php files with a constant check is too me more annoying, better to ensure all your inputs are sanitized and outputs are escaped.

    Hacker has gained access to server and can execute arbitrary php/include your file and utilize it.

    At this point it’s too late to worry about your code, they could easily define the constant you’re checking against, but more likely have no need and can do much worse without your code.

    Would love to hear your thoughts though, curious if I’m missing a situation or situations.

    • Does this truly add security though?

      Yes and no. I certainly not say that this is the most secure thing we can do (nor is adding index.php, but there are a lot of plugins that don’t offer anything.

      So at least add something that will prevent direct access for many people.

      I can think of two scenarios in which your file would be accessed:

      Great! This is what I was hoping the post result in happening :).

      File is accessed directly in an attempt to execute some malicious code against some logic your code performs

      This would work against files that are not the root plugin file, right? I mean, technically including this check in each file is important, but if you’re able to hijack a, say, hook then you’re right.

      There should always be additional checks (nonces, permissions, roles, capabilities, autosaves, ajax saves, etc.).

      better to ensure all your inputs are sanitized and outputs are escaped.

      Agree 100%

      Hacker has gained access to server and can execute arbitrary php/include your file and utilize it.

      Admittedly, there’s a lot of steps that can happen here though, right? I mean, this pre-supposes a number of poor programming practices are in place that give users far more reign over inputs, etc. than they should ever have.

      At this point it’s too late to worry about your code, they could easily define the constant you’re checking against, but more likely have no need and can do much worse without your code.

      Right — but, correct me if I’m wrong, this has to be done prior to WordPress even loading because the constant already being defined will stop that from happening.

      Would love to hear your thoughts though, curious if I’m missing a situation or situations.

      I think you’ve covered it and I’ve tried to add a few more things. Perhaps a follow-up post for this would be worth my time, too.

      Fantastic comment, Aaron. Thank you.

  3. Do you do this in files that just define a class? The only reason I can think of would be to suppress potential error messages that might supply an attacker with information about the system.

    • Usually, I actually do this in files that are procedural.

      Files that have classes, I normally try to protect through number of other strategies the least of which aren’t also just building in good security checks.

      What about you?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.