Secure way to allow user to add javascript to page

(Jason) #1

At my agency we build out custom themes and plugins for our clients on a per-site basis. It’s fun work. For the most part we have an idea of how the site is supposed to work once up and running and we make it do exactly that. Every so often, though, after a site is live, the user will try to add some javascript code they got from somewhere into the editor (usually to embed something). This makes me cringe.

Feel free to skip this paragraph, but as a note to other developers out there, please don’t encourage users to go pasting HTMl and JavaScript into random locations on their site. Give them a lib to include or use an iframe, but please don’t give them tailored JS. Even YouTube knows better. :smirk:

Anyway, what I’m really curious about is how others around here handle this situation. The most optimal solution, from a development standpoint, is for them to let us know whenever they need something like this, give us the embed code, and we’ll tweak the theme/plugin to support it. I’m tempted, at times, to allow the user to add JS in some form to make it easy for them to add stuff like that. I’m conflicted though, between my desire to help them run a fast, secure site, versus my desire to give them a CMS they feel like they have total control over.

Thanks for your thoughts! :slight_smile:

(Leland Fiegel) #2

Interesting question.

Just to clarify, when you talk about users…do you mean just your direct clients? Or are you talking about a operation where anyone can sign up and publish things?

I’m pretty sure you’re talking about the former, so I’ll respond to that.

While it’s impossible to be totally comfortable giving a client to add arbitrary JavaScript to their sites, I’d probably let them do it just as long as it’s clear that they:

  • Keep their WordPress accounts secure, so bad actors can’t add malicious code
  • Are responsible for any edits they make to the site, and liable for any damage done as a result of those edits

I’m sort of torn though, because it ultimately depends on the client. Do they have a tendency to break stuff because they go off adding random code without telling you? In that case, my opinion would change…because there’s always a more foolproof way to set it up (i.e. custom shortcode, mu-plugin that hooks into wp_head or wp_footer, or oEmbed).

With all that said, I’d have a much more strict stance on allowing access to the theme and plugin editors, which should be disabled for non-technical clients. At least with JavaScript, there’s less of a risk that an entire site is brought down with an out of place semicolon.

(Yash Chandra) #3

For me, this is the biggest security risk. I ensure that we use the following in wp-config.php

define(‘DISLALLOW_FILE_MODS’, true);

Oh and I don’t give FTP access to our clients due to the nature of the business which works well for us.

(Jason) #4

Yeah, I don’t really do multi-use themes, so at least for us the issues is unique to each client.

Good thoughts, thank you. I probably should just go the route of allowing it while making it clear that the liability is on the client. What’s especially difficult here is getting some folks, understandably, to discern the difference between something they did breaking the site, versus something we did. That’s kind of the fine line walked by a CMS – make it stable as possible, but still give the user enough rope that they can either make a pulley or hang themselves. :stuck_out_tongue:

(Jason) #5

The only thing that stops me from flipping that switch is that it also disables the ability for users to add plugins. I wish that was still possible while disabling everything else, but it makes sense why it isn’t. I don’t believe most of our clients would go for the idea that they have a massive list of plugins available to them by using WordPress, but they have to have us install them in order to use them.

(Yash Chandra) #6

Yea. For us, even if clients need a plugin, we make them ask us to install it (and we gladly use wp-cli for everything). I understand that this won’t work when clients own the site with FTP access but if you can, it helps to keep all that access to ourselves.

One argument I make is that “plugins are a big security risk and we would rather check a plugin for you before installing”. Even if we actually don’t code check the plugin, we do a quick scan and also check ratings etc. In some cases, we tell them that plugin has not been updated for over a year etc. and could pose a risk both in terms of functionality and security.

(Jason) #7

Definitely good thoughts. Thanks! So long as the relationship you have with the client is that of on-going administration, then that makes sense. You’re clearly not just providing a commodity to your clients, which is great. This is good food, for thought. I’d like to be in the position where this makes sense with my clients and it’s a no-brainer. I’ll be thinking about this. :slight_smile: