Many plugins require configuration with sensitive data such as API keys, passwords, etc. When implementing these plugins, this sensitive data is stored using functions such as update_option() and get_option().

It would be trivial to write a trojan plugin that provides a useful function but also performs a variety of get_option() calls on known-sensitive options. Even if this isn't possible, a manual SQL query can reveal this sensitive data.

Is there any way to avoid this inherently insecure model?


Actually, there's not too much you can do.

If an intruder has direct access to your site - where they can run get_option() or perform direct SQL queries - then you've already run into a problem. The safest bet here is to exercise your best judgement when installing new plugins.

In other words, the best plan of action is prevention. Don't install plugins you don't recognize or written by developers you don't trust.

While you could use encryption to protect the data, remember that WordPress itself still needs access. So if WP can read the data, then anyone who can run get_option() can also read the data.

  • What about from a plugin developers perspective? The developer wouldn't have any control over the installation of other plugins. A malicious plugin could steal data from my plugin and use it for other uses. Any advice on how a develop would secure their plugin to prevent methods such as this?
    – Elliott
    Jan 14 '13 at 0:06
  • The site owner can and should have the ability to override plugin functionality from another plugin on their site. Remember, it's their data, they own it and can do with it whatever they want. Blocking "malicious" plugins will also block otherwise legitimate plugins installed by the user. If your data is super sensitive the only way to protect it is to not include it in the plugin in the first place. Set up a SaaS system that the plugin communicates with to request that data.
    – EAMann
    Jan 14 '13 at 15:22

Yeah, don't install malicious plugins, or use encryption (see: http://php.net/manual/en/book.mcrypt.php for how to do that).

  • 1
    While I agree with your sentiment ... this doesn't really answer his question.
    – EAMann
    Jan 11 '12 at 21:04
  • Expanding on the second, more practical part of my answer... Provided you can keep your key secret, check out PHP's MCrypt: php.net/manual/en/book.mcrypt.php This would allow you to safely encrypt the data you store, and provided your key is not public knowledge you could store the data in the database in a way that other plugins would be able to read. Its not bullet proof, especially if you are distributing your plugin, but it would effectively do what you want
    – xentek
    Jan 12 '12 at 1:59
  • @xentek - What would stop another plugin from simply reading the source code in your plugin's file; then it could easily decrypt your data, and we're back to square one! Jan 12 '12 at 2:59
  • 1
    That would fall under "key is now public knowledge", wouldn't it? I find this entire discussion rather silly... if you've got rouge code on your server, you've got bigger problems that the security of some api key. However, if your system has been reasonably secured, and you've reviewed the code of the plugins you're running (you do read all of a plugin's code before you install, right?) then encrypting the data is purely precautionary and is better suited for protecting you from a lost sql dump than random get_option reads
    – xentek
    Jan 12 '12 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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