16

As a wannabe WP plugin developper, what are the main security flaws/holes I should look for?

I'm about to create a new plugin with a configuration panel (ie input fields and stuff). What should I be concerned about?

For example, is data sanitization such a big deal since it's in the /wp-admin/ area? Could someone malicious directly hit my plugin page and send POST requests or something like that?

Thank you!

Improve this question

3 Answers 3

Reset to default
16

Here is a modified checklist, based on my current (work-in-progress) settings/data security checklist used for reviewing Themes (the principles should be no different for Plugins than they are for Themes):

  1. Plugins should prefix all options, custom functions, custom variables, and custom constants with plugin-slug.

  2. Plugins should implement Plugin Options and Plugin Settings pages deliberately, rather than relying on copy-and-paste scripts from website tutorials, such as the ones below, which are outdated, and do not include proper data security:

  3. Plugins should use the add_options_page() function to add the Plugin Settings Page to the Settings menu, rather than using add_menu_page() to add a top-level menu.

  4. Plugins should use an appropriate capability (e.g. manage_options) for the capability to add the settings page.

  5. Plugins should save options in a single array, rather than create multiple options for the settings page. The use of the Settings API (see below) would handle this.

  6. Plugins should use the Settings API(see below) to get and save form input data rather than rely on $_POST and $_REQUEST data directly.

  7. For checkboxes and select options, Plugins should use the checked() and selected() functions for outputting checked="checked" and selected="selected", respectively.

  8. Plugins should validate and sanitize all untrusted data before entering data into the database, and should escape all untrusted data before being output in the Settings form fields and before being output in the Theme template files:

  9. Plugins should use esc_attr() for text inputs and esc_html() (or esc_textarea() in WP 3.1) for textareas.

  10. Plugins should explicitly provide Settings-page nonce checking, if not using the Settings API:

  11. It is also highly recommended that Plugins use the Settings API, which is easier to use, more secure, and takes care of a lot of the hard work of settings pages:

For a good tutorial on using the Settings API, see:

If you want to check out a theme with a secure and solidly-coded theme settings page, check out this theme:
http://wordpress.org/extend/themes/coraline

Improve this answer
15
  • And I should add: if anyone sees anything missing from the list, please comment, so that I can add it to the checklist, to help improve the security review for Themes!
    – Chip Bennett
    Mar 30, 2011 at 19:08
  • Wow, great list, thanks. I wonder if its worth making this question a community wiki and making each of these points their own answer to better allow discussion and elaboration?
    – goldenapples
    Mar 30, 2011 at 20:22
  • I'd be fine with that, but don't want to hijack the original poster's question (unless that's how things are done on StackExchange? I'm still new here...).
    – Chip Bennett
    Mar 30, 2011 at 20:24
  • I dunno either... leave it up to moderators discretion, I guess. This seems like it would make a great wiki question, as its so important and best practices are still being working out. @Rarst?
    – goldenapples
    Mar 30, 2011 at 20:26
  • I could create a new Question, if need be?
    – Chip Bennett
    Mar 30, 2011 at 20:28
11

There are two aspects to this:

  1. Basic principles.

    • Whatever is written into database should be checked for SQL injects.
    • Whatever is printed to screen should be checked that it doesn't print harmful JavaScript.
    • Whenever someone does something it should be checked that it was his intention to do so and he has appropriate capability.
    • There are many many more things that you or me either won't ever think to check for.

  2. Specifics.

    • Modern WordPress takes security seriously and aims to make it easy for developers.
    • So for most of things you want to do there is most likely a way to get it done with WP APIs.
    • So whatever you are doing your first step would be to fine and study appropriate API.
    • The further you are from common and simple functionality the more complex things you will need to study and implement.
Improve this answer
1
  1. Add defined('ABSPATH') or die('Access denied'); at every plugin's script that used by wordpress directly
  2. Add empty index.php file at every directory
  3. Add .htaccess in plugin directory with needed instructions for prevent direct access to certain plugin's files.
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.