A few months back, I wrote a post about getting your support request to the top of the queue. In it, I casually mentioned that I felt inviting third-party developers into your ExpressionEngine environment as Super Admins was a security risk and it should be avoided. I’ve since had a few conversations with other third-party add-on developers who expressed their disagreement with this position.

I’ve thought about it quite a bit, considered all of the angles, and came to the conclusion that inviting third-party developer into your environment as a Super Admin is, in fact, a security risk.

Maybe it’s my background in banking software, or perhaps it’s shell shock from having to endure full-scale compliance department security audits on numerous occasions, but my mind is now conditioned to smell a security risk at every turn. I know this isn’t a popular opinion and I realize that it makes the process of successfully identifying an issue that much harder, but it doesn’t make the vulnerability any less real.

All it would take to ruin the good reputation that the ExpressionEngine third-party community has worked so hard to attain is one unscrupulous developer who decides to use their Super Admin access for their own benefit. Remember, Super Admin rights in ExpressionEngine’s Control Panel give any user access to a full MySQL Manager. This alone should scare the pants off of anyone considering granting this kind of access to someone who doesn’t work for their organization.

Good Points

All this said, my conversations with other third-party developers brought some really good points to my attention:

• Without Super Admin rights, you cannot access the template debugger.
• In many situations, you cannot adequately duplicate the problem without being able to duplicate the environment the end-user is working in.

Template Debugger

Currently there is no way to create a member group other than the Super Admins which can view the template debugger. In the grand scheme of things, this is an easy feature to miss but, when framed in the context of this issue, it becomes a crucial one to add. If anyone from EllisLab is reading this: please consider adding this feature to help keep the ExpressionEngine community secure.

Best Practices

1. Use a Development Environment

You should never invite another developer into your production environment. Ever. If you don’t have a development environment where you can replicate the issue, you’re doing it wrong. There is no excuse for not having a development environment to test your new code and troubleshoot issues, plain and simple.

2. Make The Changes Yourself

Assuming you are using a development environment and the developer you have invited in has resolved your issue, ask them what they changed and make those changes yourself in your production environment. This accomplishes two things:

1. You will gain a better understanding of the add-on you are using by seeing what the developer has done.
2. You can rest easily knowing exactly what has changed in your code.

3. Create a New Member Group

As I mentioned in my previous post, there are some issues which simply cannot be resolved without granting a third-party developer access to your environment. In these cases, the best practice is always to grant them the least amount of access necessary to hunt down the issue. If the developer needs additional access, they can ask for it and you can grant it, but you will at least have a good sense of exactly which portions of your data are currently open to another developer.

What access is needed depends largely on the problem and the add-on in question. Developers will know what they need access to, all you need to do is ask them. Take the extra five minutes to create a new member group and assign them to it.

4. Understand Member Group Settings

This goes without saying, but you should understand exactly what rights you are delegating when creating a new member group. At the very least, pay close attention to these options when creating a member group for your guest:

• Security Lock: Should always be set to Locked
• Private Messaging Privileges: Although I don’t know anyone who uses this functionality, for safety’s sake, it should be turned off across the board.
• Control Panel Access
  • Can access TOOLS: Data: This is where the MySQL Manager resides, for the love of God set this to No.
  • Can access CONTENT: Publish: Unless your issue stems from the publishing of new content, this should be set to No.
  • Can access CONTENT: Edit: This will likely need to be set to Yes, however there are steps you can take to make this more secure. Create a duplicate entry of the one in question, using your newly created temporary developer as the author.
• Control Panel Access: For the most part, you need to use your best judgement in this section. Unless the issue you are experiencing is directly tied to any of the functionality listed in this section, everything should be set to No.
• Channel Posting Privileges: The goal of this section is to only allow the third-party entering your system to have access to content you have created for them using their account, but the biggest security issues are:
  • Can edit entries authored by others: No
  • Can delete channel entries authored by others: No
  • Can change the author name when posting channel entries: No
• Template Editing Privileges: Your guest will, in many cases, need access to your templates to play around. Give some consideration to which template groups are used in the page in question and only allow access to those. Your developer may come back to request more access as necessary but at least you’ll know which templates were open.

I have not listed every setting here, just the ones that one’s which pose the greatest security risk.

Understand Your Problem

The best thing you can do, prior to inviting a developer into your environment is to know your problem. Take the time to consider the following:

• Which templates are being used when I experience the issue?
• Which other add-ons are being used on same page as the issue?
• Can I replicate this issue in my newly created member group?

These questions will not only help inform the way you configure the member group you will create, but will likely be very useful information to the developer you are requesting services from. Pass it along to them. There is nothing worse than getting a support request which simply reads: “Your add-on doesn’t work on my site.” No developer is going to complain about being provided with too much information about an issue.

Check Yourself

Remember how I mentioned that you should keep track of all the template groups which you were granting access to? Take a few minutes and read through them, just to be sure. If the developer has fixed the issue in them, you will have a better understanding of how their add-on works. If someone has done something wrong (intentionally or otherwise), you’ll be able to identify it.

Let’s Talk About This

I realize that this makes more work for everyone involved and we are all already busy. At the very least, I’d love to see some discussion about this issue, perhaps in a panel at one of the many great conferences in or around the ExpressionEngine community. I think that with a discussion between users and developers, we could easily create a secure standard for how to best address issues in third-party add-ons.