WordPress is the world’s No. 1 CMS. But is this ubiquitous, open-source platform secure enough to handle the worst threats today’s Internet can throw at it, especially at the enterprise level?

There are a lot of myths and biases out there. For example…

Aren’t WordPress websites vulnerable to hackers? Isn’t open source code easier to penetrate? Wouldn’t it be better to take security in-house? Aren’t all WordPress instances the same?

This webinar will bust more than a few with our guest security experts from Fresh Consulting and WordPress VIP. 

Key takeaways:

• Why open source is a good security posture, not an inherent vulnerability.
• Best practices in developing secure WordPress themes and choosing the right plugins to prevent data breaches
• What you need to know about security at the CMS host level, e.g., containerized databases, permissions, and penetration testing.
• What your average WordPress content marketer really needs to know about security before they hit “publish.”

Transcript

Tess:

So welcome to our webinar Demystifying WordPress Security. Like I said, we’re just really excited that you’re here. We’re excited about this topic. It is something that’s really near and dear to our hearts. So as I said before, feel free to put questions into the little question box and we’ll have time to answer them at the end. So today’s session is going to be about myth busting, WordPress and web security. So we are looking at what are some of the myths, what some of the FUD, the fear, uncertainty and doubt about website security and WordPress security. And we are going to try to debunk those myths for you today.

So I’m Tess from WordPress VIP. I’m going to be hosting the session today And joining me, we have two experts in WordPress Security. Ayush Malakar is a WordPress developer with fresh consulting. Ayush is a full stack and WordPress developer with nearly 10 years of experience in the web industry. And we also have Sean O’Shaughnessy, lead solutions engineer at WordPress VIP. So Sean leads the WordPress VIP solutions engineering team and has a decade and a half of experience with WordPress. So welcome both of you. Thank you for joining us.

Ayush Malakar:

Thank you, Tess

Sean O’Shaughnessy:

Thank you for having us.

Tess:

We’ll just get into it. So our first kind of myth or that we’re going to bust is about open source. WordPress is famously open source software and having all of that code out in the open can feel like a scary proposition for businesses. So Ayush, I’m going to ask you first of all, what does open source even mean? Who’s writing the code here?

Ayush Malakar:

So great question, Tess. So on a very high level, what open source means is the code that helps run or that’s been written to help the software to work. So that is visible for anyone to see. So even individuals who are not developers can go into the repo repository, can view the code and just see what’s going under the hood. And the great thing about open source is the visibility, but at the same time a lot of people do argue that having code exposed like that to the public can create uncertainties and also possibly make the program more vulnerable. However, we can also use the same point as a current counter argument to say that since we have so many eyes looking into it that it’s more safe. And at the same time what we should also understand is not all open source are built the same way.

Now when you talk about WordPress and how its ecosystem works, so WordPress has been around for 18 years and also holds around 43% of all the websites that are running on the web. So if there was any vulnerability or any security issues, I doubt we would see these numbers growing. And the one nice thing about WordPress and open source in general is that they also offer bug bounty programs. So these programs encourages people around the globe to come in and to actually do some attacks and try to figure out if certain sessions of the application is secure or not. So in a way, open source does have a great potential to be more secure than its closed source counterparts.

Tess:

Interesting. That’s definitely a myth that I’ve heard. So it’s good to talk through what that actually means. You mentioned the bug bounty program. What does that actually mean?

Ayush Malakar:

So what a bug bounty program offers is it’s asking developers not only from a specific team but from around the globe to say, “Hey, come check out our code, try to find the vulnerabilities in it and if you are able to find any vulnerabilities, let us know and we will happily in incentivize you for the vulnerability that you found.” And some of the bug bounties that are encouraged are brute force denial of services, phishing, cross-site scripting with the WP admins page and text injection SQL injection and so on.

Tess:

Cool. So you mentioned that there are a lot of people contributing to WordPress and also anybody on this webinar is welcome to go and contribute to the WordPress project, but sometimes we see a WordPress security update and that can feel a bit alarming sometimes with like, “Oh, was it not secure before?” So what actually happens in those WordPress security updates? What’s going on?

Ayush Malakar:

So whenever a WordPress security update is made, so it might be because there might be a vulnerability that was not found during testing or during any integration or at some point something might have fallen under the cracks. But the great thing about the community is everyone comes together and patches the code and before pushing the code out, the code is tested and ensure that there are no other remaining vulnerabilities. And once the code has been pushed out, everyone gets a notification on their WordPress dashboard and saying there’s an update. Now when the update comes in, it’s nothing really alarming. We can either auto update it or you can manually go and update your website, which in turn makes it more secure. Now if let’s say if no one actually got in and we’re viewing those vulnerabilities, chances are someone would use those entry points for nefarious reasons into your application and seeing how the community is actively working to patch all the holes, from what I can tell, it is secure and it’s getting to a point where and that no one wants to go in and start putting in wrong code.

Tess:

Right. Sean, is there anything that you wanted to add about open source security?

Sean O’Shaughnessy:

Yeah, sure. Having worked in WordPress for so long, huge fan of open source software and I think when you put that against the sort of closed source counterpart that some of these systems run, one thing we maybe didn’t mention or talk about is that you don’t know when these types of vulnerabilities or exploits are taking place against things like closed source software and you’re additionally beholden to a very limited team of folks, the maintainers of that software to provide those security updates versus the vastness that exists around something like WordPress’s contributor community.

Tess:

Cool, good point. So for this particular myth, although it might seem counterintuitive, I guess we can say that open source software can actually be more secure than closed source or proprietary software. Onto the next topic, which is about the code. So we spoke about WordPress core. We aren’t going to cover core very much in this webinar because, as we mentioned, it’s developed by the community. And while we’d strongly recommend getting involved in that community, we are going to focus the webinar more on the things that we can control more, which is like your theme or application code and plugin code. So that code is on top of the WordPress core code. And so we’re making a distinction between those two buckets here. So we’ve got the WordPress core as one bucket and then your application code as the other bucket, being your theme or front end and plugins. So in terms of that code that we’re developing ourselves or that we might be using third party plugins for, Ayush, what are the main sort of attack vectors of WordPress websites?

Ayush Malakar:

So primarily, the main attack vectors would be the WordPress score. However, since the community takes great creative fit, we don’t need to worry about that. The other two would be the plugins that we install and the teams that we write or install from a third party. So we need to be aware whenever we choose a team or a plugin that number one, it has great ratings and it’s approved by the community and it has gone through all the processes of checking reviews to ensure that there is no potential path for vulnerability. So basically make sure when you choose themes or plugins, it’s a good theme or plugin and it’s from a known source and you don’t just pick and choose whatever we find off the internet. And it is also up to us to make sure the tools we choose have security enabled in them.

Tess:

Or you write them yourself, but in either way, are there tools that you recommend using to ensure that security?

Ayush Malakar:

Absolutely. So whenever we talk about tools, we need to understand what are the pros and cons of this tools and how we should best use the tools to our advantage. So some of the tools that I use or that I would recommend are WP Scan. So WP Scan is an open source tool which helps to identify any known vulnerabilities or any known issues with the most popular plugins in the WordPress repository or just either whether it’s paid or whether it’s a free plugin. Another tool that I use is PHP code sniffers and WordPress coding stands for code sniffers. So before using these tools, primarily when I used to develop, I didn’t know a lot about what vulnerabilities my code introduced, but after running these tools, I noticed for example, whenever I was running an Ajax request, I noticed that I was missing none. So these tools actually helped me become a better developer in terms of security and in terms of understanding how we should write our code.

Another way we also would be to use static and that dynamic code analysis. So on a very high level, static code analysis means we are just pushing the code to an automated system which checks our code based on past bugs or vulnerabilities and shows us potential and lets us know this particular code snippet has the potential to be vulnerable and it also gives you recommendation on how you can use it or how you should change about. Now when you talk about dynamic code analysis, what this means is we go through and we run rigorous testing. For example, we’re running a piece of function, you need to understand that whenever we pass any variables into the function, whether we are passing boolean value, whether we are passing a string value, we should understand how our code interprets those data and how it’s being used in our codes. We don’t want just anything going in.

So dynamic code analysis also helps understand other components like the SQL part of WordPress. What it does, it helps alleviate all those unknowns. So another tool that I would recommend using is maybe bots, ML AI features. So what they can do is they can be the first line of defense in order to understand common vulnerabilities that might be introduced and then later on, a human going in and doing code reviews. That is what I would recommend as tools.

Tess:

Okay, awesome. So like a balance between using the bots and using humans. Sean, is there anything else that you wanted to add in there about tools that you’ve used or [inaudible 00:11:26].

Sean O’Shaughnessy:

No, my experience is very much the same, especially around something like phpcs and when you can reach for or pull in the rules that are very specific to WordPress and applying that static analysis to your code I think is a good first step towards just covering off on some of the basics. Are we doing the right amount of input validation? Are we properly sanitizing any output we’re going to have within our code?

Tess:

Awesome. And what about plugins, Ayush, because often developers are writing their own themes but they might use a lot of third party plugins. So how can people ensure that those plugins are secure and is there a need to also add like a WordPress security plugin, which there are also plenty of out there?

Ayush Malakar:

That’s a great question, Tess. So when it comes to plugin, what I would recommend is understand the type of plugin you’re using for and understand what it is doing. Now if you’re talking about an e-commerce, the WordPress repository has a lot of different plugins for that which are very high rating. And I think I would recommend just using one of those. However, if it’s a simple case of adding a copyright to the theme or some very minimal changes, what I would recommend is writing the code within the team itself because what I’ve seen in the past is code which works or plugins, which do a very minimal job to make any updates or make any changes on the website normally don’t get updated. And chances are, as technology evolves, those plugins do not. And the potential of those plugins introducing vulnerabilities might be higher than what we’d anticipate.

So just do your due diligence, understand what plugins you’re using and make sure whatever plugins you’re using at the same time has been vetted by the community and other developers and it’s being used frequently. And as for security plugins, now that really depends on the host. So if you’re talking about a standard Linux host with bare minimum operations going on, sure, it helps. But if you’re talking about a host which already does security for you, chances are you might not need a workplace security plugin cause the host takes care of it.

Tess:

Cool. And then all of those tools that we mentioned before, I suppose you could run those on those third party plugins as well and get the same feedback I guess as you would get for your own code.

Ayush Malakar:

Definitely. So for the third party plugins, I think the best one you could use would be the WP scan. So I’ve used WP scan in the past and some of the active plugins that I was using, it pinged that there was a vulnerability, however that vulnerability has been patched and now once the patch is out there, it’s up to us to do a due diligence and make sure we apply it in our software so that the potential for the system to get hacked would be minimized.

Tess:

Yeah, for sure. And you mentioned due diligence. Do you have any other best practices or tips in regards to that that you can share things that you do?

Ayush Malakar:

Sure. So understanding the ecosystem and the project you’re working on is vital because that way, whether you’re working on a standard block page or a heavy e-commerce page, security comes with its benefits. So I wouldn’t say we need to dive heavily if you’re just using a standard blockage. However, if you are running a full scale application on WordPress, especially an e-commerce website, I would say security would be your vital aspects as well. And now since we are using third party plugins, at times, they’ll have updates, and at times, due to the bug bounty program, individuals can identify their vulnerabilities. But once those patches have been put out in the world, it is up to us to ensure that those patches are within our system.

Tess:

For sure. Sean, do you have anything else to add about best practices for securing your own code?

Sean O’Shaughnessy:

Yeah, and think it goes back to the word you used earlier around diligence and understanding your application, knowing where are the spots that within that application we maybe need to look at and apply a little bit extra security. So looking at or talking about things like what is XML-RPC, how does the REST API that comes with WordPress itself factor into the types of things we need to put in place? But these things don’t, they’re not there and by default creating any sort of concern around security. I think in some earlier discussions we were talking about castles and drawbridges and how you have this castle WordPress your application and having the presence of a drawbridge doesn’t inherently make your application insecure, but it is an avenue, it’s a way into that castle. So just having a good understanding and knowing and accounting of those things is definitely vital towards having a better posture around your application security.

Ayush Malakar:

And-

Tess:

Oh, so there… Oh sorry, go ahead. Go ahead, Ayush.

Ayush Malakar:

So falling back to Sean, sorry. So when we were using the REST APIs for our application and we were doing quote reviews, we found that some of our datas were unintentionally being exposed. Now if you weren’t doing any sort of code reviews or static code analysis on our end, I doubt we would’ve caught that and at the end we would be just pushing vulnerability to our website. So I just wanted to expand on what Sean said.

Tess:

Yeah, for sure. So basically in terms of busting this myth, there’s really in your control and there’s lots of measures that you can take to ensure that your application code is as hardened as possible against attacks. And there there’s an element of deciding what the risk benefit is for particular applications. So if you aren’t using those endpoints like the REST API, then maybe you can shut those off and that just shuts another one of those drawbridges. So it’s really about determining what the needs are of the application and against those possible attack vectors, but you sort of need to be aware of those first.

Okay, awesome. Our next topic is about hosting. So we’ve got all of this code and we have to host it somewhere, so it’s just an important consideration to think about how secure your host is. So Sean, starting with the broadest level, what should people look for in a host?

Sean O’Shaughnessy:

Sure. Yeah, good question and definitely a fundamental part of the other side of the equation. You’ve got the application and now it’s where do we put this application? And I think when it comes to looking for a host for your WordPress application, a couple important things come to mind. I think about a shared responsibility. Is your hosting provider vested and committed in helping you and providing you with the right tools and functionality to keep your application secure?

I’m looking at things like are they offering fast and proactive support and then additionally maybe, and as a part of how vested they are in your security process and your application, what are they doing? How are they responding when application or plug-in vulnerabilities are published, for example. So as an example on VIP we keep up with the reporting of plug-ins in the community at large. We’re constantly taking that and measuring it against our customer base and then making a determination of how can we best protect our customers and we’ll even go as far as putting mitigations in place within our platform functionality that the hosting level itself.

Tess:

Awesome. And there are a few kind of things I guess features that you might see of hosting providers that it might be good to chat through what those actually do when they’re talking about security. So one thing would be the file system and how to handle permissions. So what does that mean in terms of security?

Sean O’Shaughnessy:

Sure, yeah. And super important as well. For me, my prior experience, I’ve spent a fair amount of time unfortunately cleaning up disinfecting compromised WordPress applications. And I would say by and large how that happened is almost always the same. We have weak passwords that are easily brute forced and then we are doing things like having very liberal permissions applied to the underlying files because we may have encountered a problem and we Googled and we found a result. It was like, “Oh, you just need to make your file permissions like world readable and writeable,” and this is generally very bad advice.

So when we talk about the file system, having an understanding of those permissions and where to apply the right permissions is super important in the context of a WordPress application. The process, the background daemon that runs that is responsible for serving responses, be it Apache, be it PHP-FPM, should be different from the owner, the group, the permissions that are applied to the underlying files to prevent things like a nefarious actor. Again, they use WordPress theme editor and they bury malware or what’s called a web shell, which basically allows them to do all sorts of fun stuff within your application within the code.

And they’re very crafty when it comes to doing this. They will bury files in like a wp-includes folder or make it look like it’s a file that should be a part of WordPress. And at first glance it’s easy to miss. So maybe even taking extra steps here around protecting these files, making sure that the files operate or run in a read-only state. Goes a long way towards… In worst case scenario, this compromise does happen, the blast radius or the damage that can be done can be limited.

Tess:

And take it from Sean. You do not want to be spending your time cleaning up compromised word reasonable divisions.

Sean O’Shaughnessy:

Not fun. Not fun.

Tess:

Okay. So another feature that might be seen in hosting is containerization having containers. What does that mean in terms of security?

Sean O’Shaughnessy:

Sure, yeah. And we do this on VIP currently and going back to the file system stuff. We have and build docker container images and that locks in place what the code looks like at any given moment. But for containerization as a whole, it’s a great way to provide a level of resource isolation. But the important thing I think to note within it, if you’re doing or employing these practices, it’s not comprehensive. There’s additional steps that need to be taken to further harden or restrict those application level containers that have your application code in it. So for example, a great practice might be to set up ingress and egress firewall rules that say this customer’s application is not allowed to talk to this other customer’s application or exchange data between them. Doing that, and we’ll talk about this a little bit more, but having multiple layers of defense in place, don’t just look to containerization as a means to maybe give a false sense of security that that in and of itself is enough.

Tess:

Yeah, good point. One more thing that’s often seen as a feature in hosting is version control. And so what does that mean in terms of security as well?

Sean O’Shaughnessy:

Sure, yeah. And Ayush, I’m going to call on you in this maybe, but coming from a developer background, version control is incredibly useful and I would argue that it’s definitely a best practice. I think if you’re taking application code and then you’re just simply drag and dropping it via SFTP to deploy it onto your host, that you’re doing yourself a disservice. Having that version control in place provides this full auditable, rich with context history way of examining the entire genesis of your applications code. I can go back and see that Ayush made certain changes a month ago, what those changes were and even why he made them. And through that, we get a pristine copy of the code, we have a representation of this is what this code is and should be and we know any potential modifications outside of that should raise suspicion that it’s not a valid part of the application.

Ayush Malakar:

So version control can be used as a source of truth to see what files have been checked. And when we go into the host and if you see different files, we can also use a kit deployment process to ensure that those files get removed and only the files that we have in the repository is what we have in the host.

Tess:

So the days of accessing all of your files over SFTP is probably over or should be over if you’re concerned about security.

Ayush Malakar:

Should be over.

Sean O’Shaughnessy:

I think it’s still very prevalent, but it’s a very hard thing to get out of.

Ayush Malakar:

That’s true.

Sean O’Shaughnessy:

It has deep roots in the history of how web applications came to be and how they’re deployed. But I think a more forward-thinking, secure mindset comes from adopting things like version control as a start.

Tess:

Yeah, definitely modernizing that aspect. Ayush, is there anything else you wanted to add about hosting security in general?

Ayush Malakar:

So I think Sean answered all of our questions, so I think I would just follow back to maybe a plugin. Now if you have a great host, I would echo not using a plugin, but depending on your host, maybe a plugin would be beneficial. But other than that, Sean said it best.

Tess:

Awesome. So to sum up this myth, again, there are a lot of considerations to make when you’re determining if your host is secure enough and to consider all of the options… And don’t forget about the importance of the support that the host offers as well. I know that we had a recent plugin security incident where a plugin updated and introduced a new vulnerability and so our support team was able to get right on that and fix the problem across all of the customers who were using it often before those customers even knew that it was a problem.

So something like that. Something not just the nuts and bolts of the hosting, but also does the support team respond if there is a security incident, I think, is another really important aspect. And to go deeper into that human level because we’ve talked about bots and we’ve talked about code and we’ve talked about hosting, but the next myth or that we can bust or issue that we can talk about is this security on the human level at the company level and all levels of the company how we consider security. So Sean, what can organizations do to enforce security?

Sean O’Shaughnessy:

Yeah, I think it comes from a couple different things. Some words, some phrases you hear constantly. Things like zero trust, things like least privilege, things like access management. In a zero trust model specifically, we’re talking about how we can operate with multiple layers of security stuff in place that we’re not just blindly trusting that because traffic arrived from a specific or known location that that’s it. Getting out of this mindset of once you’re behind the wall you have full access to everything. So definitely at an organization level, it’s important to think about not having that mindset, but instead thinking in terms of putting multiple layers of continued authentication or validating in place.

And then when it comes to at least privilege, we’re talking about giving the users of the organization the most privileges they need. Not all privileges. We don’t want to just make everyone an administrator because we can, but really thinking about what is the least amount of privilege or capabilities that this user can have within this application. And super important. And WordPress is great here at this because WordPress has this very strong roles and capabilities system built right into it. And then through that system, we can go further. We can define roles and permissions and capabilities that make sense for our organization if we find ourselves maybe needing a little bit more than what WordPress has out of the box. So what do you think, Ayush?

Ayush Malakar:

Well, on a very high level, but in terms of what a company can do, I think another thing that we can do is when we add SSO, perhaps trying to use 2FA as well. So it might seem overkill, but when it comes to security, I don’t think there’s something as overkill. The more you have, the better it is and the better sleep you get at night.

Tess:

We all want better sleep. So that’s good that you brought that up of SSO and two factor authentication. And that also leads me to think about regular users of the website. So the content creators who are in that website all the time and can they just think, “Oh, well everybody else has dealt with the security and so I don’t need to,” or what are some things that they can think about? And I think two factor authentication on passwords is a good one, but Sean, what else can regular users of the website do to think about security?

Sean O’Shaughnessy:

Sure, sure. And especially coming from an organization level, the users themselves should have and adopt just good password hygiene or as we refer to it as password hygiene or maybe other folks too, but it’s having things in place that sort of dictator or require that passwords vary in characters, uppercase, lowercase, they have letters, they have symbols. I always think back fondly of the xkcd comic about correct horse battery staple and it’s this comic that says don’t use certain types of passwords, but instead think of it in terms of words and then it goes into illustrate how long it would take a computer given a thousand guesses a second to guess that my password is correct, horse battery staples. So good password hygiene I think is a great starting place at a minimum for sure.

Tess:

You just shared your password with everybody now on this.

Sean O’Shaughnessy:

I know. It’s correct. Horseman. Don’t tell everybody,

Tess:

We’ll just remove that bit from the recording.

Sean O’Shaughnessy:

Right, right. Yeah. And then behind that we’ve said it’s multifactor, two factor authentication. And you said it’s maybe looking to things like an identity provider to give a single sign-on within our organization. I don’t think something like single sign-on makes the approach more secure inherently, but it does centralize that the user management across all the supported applications.

Tess:

So if you think about someone leaves the company and you need to off board them, that’s probably good to have that as a centralized place.

Sean O’Shaughnessy:

Exactly, exactly.

Tess:

Ayush, is there anything else that you wanted to add about users and security?

Ayush Malakar:

Well, at the end of the day, it depends on how you set it up on and organize, but at the same time as an individual, I think the best practice is password hygiene if you’re using any passwords to access your websites. And also make sure whenever you click on links that it’s a trusted source and it just doesn’t take you to a place where it asks you for your password, be vigilant in the web. We are all aware of phishing scams when it comes to open source applications, so please bear in mind all of these factors.

Tess:

Cool. So to wrap up on this topic, basically security is not just at the code level or the host level. There are also very real human factors to security. And so companies can build in things like security checks regularly and password hygiene rules and that will also go a long way to increasing the security on your website. Cool. So we’re almost at the end, I just wanted to recap some of the main points that we’ve talked about and then we can go into questions. So please feel free to add your questions into the question box if you have some burning WordPress or web security questions for Sean and Ayush. So just to recap the main topics that we talked about, open source has security benefits because there’s just so many individuals keeping an eye on it, really important to keep WordPress and plugins updated and it’s up to the individual site owner to make sure that that happens.

Use version control so you can audit changes, you can roll back if needed and you have that single source of truth that doesn’t expose your files through something like SFTP. Understanding the WordPress endpoints, we talked about XML-RPC, we talked about REST API. So if you don’t need those things, you can disable them and just cut off that one extra security vector that and look for a host that accounts for security. So not only looking at the hardware of the host and their security certifications, but also that they have proactive and emergency support available and the importance of adopting mature security practices on the organization level. So giving users the least privilege possible and that password hygiene that we talked about as well. Okay, cool. So let’s go into questions. Are you ready, Sean and Ayush?

Sean O’Shaughnessy:

Good to go.

Tess:

Okay. We’ve got some questions. So first, what about using a firewall service provider like Sucuri? Who would like to answer that one?

Ayush Malakar:

You should.

Tess:

I don’t mind. Yeah, I’m okay. Yeah great question. These things definitely can be beneficial, valuable. I think maybe the question is specifically talking about a web application firewall and to that end, I think the most valuable piece is that a web application firewall can provide or speak to is defense against SQL injection and maybe some attempts to do what’s called remote code execution. This is where part of the code allows the attacker to run code remotely on the server, maybe further compromise or infect the underlying system within that.

And I think important things to take into account in the context of that is just having an understanding of how those things work with or mesh with things like how your application caches responses. Are we just working off of that cache or are we actually checking these types of requests as they’re coming through? What do you think, Ayush?

Ayush Malakar:

No, I think that’s great. So my opinion on firewall is, like I said before, it does depend on the hosting. And having a firewall doesn’t necessarily mean that it will introduce any performance issues or any other issues on your application. So I think it does add value. I’ve used Sucuri in a lot of different projects, and the nice thing about Sucuri is that they give you a backend where you can monitor all of the applications or all of the IPs coming in and it’s easier to manage all the security within it.

Tess:

Okay, great. Thank you. Next question, are the relevant files of plugins removed from the backend while uninstalling the plugins? Or do we have to remove the scripts or everything manually? So that’s if you are uninstalling a plugin process.

Ayush Malakar:

So the process generally would remove all the folders and all the root files of the plugin on the folder. So we do not need to go in and remove it manually. Unless we’ve tinkered with it with the plugin, then yes, I would recommend going in manually. But other than that, the standard WordPress deactivation and uninstallation should take care of all your needs.

Sean O’Shaughnessy:

Yeah, I would [inaudible 00:37:16] oh sorry, go ahead.

Tess:

No, you go ahead.

Sean O’Shaughnessy:

I was going to say that it’s very much implementation dependent. The author of a given plugin or theme needs to have thought about and taken account within those hooks cleaning up after itself and not leaving any leave behinds in terms of files or artifacts from that plugin’s functionality.

Tess:

I guess the other thing what I was going to say, and this is a disaster scenario, but if the plugin has introduced security problems, there might be stuff all over the place that has come in through the plugin that’s not going to be uninstalled when you uninstall it. So sorry to be doom and gloom, but just mentioning that too.

Sean O’Shaughnessy:

Well, and especially too when we’re talking about some of the stuff we mentioned earlier around having your code base live in something like source control management. If you’re doing that, then clicking remove and the admin is likely not going to work or worse, you’re just going to end up deploying that plugin right back into your application the next time you pull your changes from that source control. So if you need to remove a plugin and you’re doing what I think is the smart thing using source control for your code, take a look at that plugin and see what it would do when those steps run from the plugin to remove or uninstall or deactivate.

Tess:

Yeah, that’s a really good question because we’ve said that everyone should do version controls, so that’s actually a different process to uninstall. Okay, next question. How long do we need to wait before updating the new version of WordPress core and plugin versions? That’s a good question.

Ayush Malakar:

That’s a good question. I can take that. So whenever we are updating a core or a plugin to a newer version, it depends on how the hosting has set up your performance. So sometimes it can be in a couple of seconds, sometimes depending on how much you’re updating, it can take around maybe five or six minutes at most. But other than that, it shouldn’t take quite a while. It shouldn’t take more than that. But even I’m stretching 10 minutes honestly, but it doesn’t usually take that long.

Sean O’Shaughnessy:

And I would say the answer here varies based on who you are, what your application is used for. You’re talking to maybe some of the enterprise level customers that VIP that we’re working with and having a mindset of just immediately updating comes with a level of risk. So through this, I think the answer is, it depends. It comes with having a good understanding of what those updates are going to bring. You’ll hear or see frequently in WordPress in the communities always update plugins and themes. And I think the answer, there’s a little bit gray there in terms of…

But also look at these plugins and themes. Are you seeing that an update is available because that update is going to maybe patch some sort of vulnerability or is it because they added a new feature that you wouldn’t need rely on or use anyway. And then make that determination and test. Have environments that you can send your application code to before putting it out on your live site. The last thing you want to do is install an update to a plugin as an unintended side effect of breaking a key piece of functionality within your application.

Tess:

Yeah, that’s a really good point. Okay, so I don’t know how much experience both of you have with other enterprise content platforms like Contentful, AEM, which is Adobe Experience Manager and Netlify. Do you know how WordPress security compares to those other platforms? It’s okay if you don’t because I know you’re WordPress experts

Sean O’Shaughnessy:

Ayush? Go ahead. Do you have anything?

Ayush Malakar:

No, I was hoping to take a pass on that because since we work with WordPress, we know how WordPress works. So I don’t know, Sean, do you have any insight on that?

Sean O’Shaughnessy:

Yeah, a little bit. I think to put them in any comparison that seeks to frame them as apples to apples works in some aspects, but not in others. When we’re talking about things like containerization host at the security level, how vested or interested that host is in having a part in the security of your application, then yes, those things are still very important. When it comes to platforms like maybe Contentful, Netlify, these are platforms that are deploying a whole different type of application. And I think there’s definitely overlap in terms of the types of security challenges and problems that platforms like that face. And then there’s the ones that aren’t going to be specific to WordPress and very specific to the types of code and applications that those platforms run. So

Tess:

Thank you. There’s a question around the names of the tools that you mentioned. I think people would like a list of them or something that’s a bit hard to do live, but I will say to that person who asked the question that we will be putting out a blog post after this webinar. I’m writing it, and I’ll be listing the names of those tools and link to them as well. But hopefully we can also get back to you here in the chat so that you can get started on those tools. Sean, you mentioned about customized user roles. There’s a question here, could you elaborate on those? Is this only by using a plugin?

Sean O’Shaughnessy:

Sure. It’s not only by using a plugin. There’s a couple of great plugins out there that provide an intuitive, easy to navigate visual way to create new roles, but all they’re doing is taking advantage of the underlying pieces of WordPress core that facilitate those roles, defining those roles, defining the capabilities within those roles. So I would say it’s up to you if you aren’t really comfortable with getting into the internals of building out custom roles and capabilities, reach for something like a plugin that offers that functionality. Otherwise, you would know how and where to put it within your application code.

Tess:

Great. You mentioned doing an audit or code review for vulnerabilities. Could you share a small snippet of your process in doing this audit?

Ayush Malakar:

Sure. So we use a tool called Sonar Cloud for a static code on analysis. During one of the analysis on the sonar cloud, they showed that our code within a function, it was a cipher code. I can’t go into any more details. It showed that the way we were randomizing the numbers was insecure and was cryptographically incorrect. And what it did was it showed us a better way as to how we could write our code and how we could prevent search vulnerabilities. I do have a screenshot here, but I am not sure how I would be able to show what I saw. Those compliance solutions, the system giving you recommendations for now. Let me see.

Tess:

Yeah, I’m not sure that you can show something. Sorry.

Ayush Malakar:

Yeah, no, sorry. That was one of the vulnerabilities that we caught head-on.

Tess:

Awesome. Another question, how practical or difficult is it to decouple the WordPress admin area from the front end of the site for visitors? So the general public can’t even get to the WP login .php URL?

Sean O’Shaughnessy:

Interesting.

Tess:

Who would like to take this?

Ayush Malakar:

I think this concept of under what we like to call a headless CMS. So on a very high level, the way the concept works is we leverage the WordPress API and completely decouple the front end and the backend. The backend will still remain WordPress. The front end, however, is mostly we generate the front end using a static site generator like Gatsby, maybe Next.js. And the way we would do it is the data would be prefilled via the API once someone makes updates in our WordPress website. It gets piped into our static code generator. And once the static code generator, it’s been fully compiled, and whenever the user goes in and visits the website, they are presented with a static version of the website. So they don’t have access to the WP admin site, they don’t have access to the WP include site. Everything has been completely separated.

Sean O’Shaughnessy:

That’s interesting. I interpreted the question in a very different way. Oh no, no.

Tess:

It’s also a good topic though, right?

Sean O’Shaughnessy:

Right. Yeah. But I’ve seen this before where folks want to separate the administration side of WordPress from the front end side. And I think before you get to talking about a decoupled implementations through no JS or different avenues there, I think doing this gives you a false sense of security. So at the end of the day, the front end of the site is pulling the content in from the back end and having that layer doesn’t really change, doesn’t change much there. It’s all going into the same database essentially. So I think there’s a high level of technical complexity that would be required to do something like that for very little benefit or trade off or mostly security through obscurity.

Tess:

Right? Yeah. So I also read it the same as you, Sean. So thinking about just I’ve seen people rename the login URL or something like that. So like you say, security through obscurity. I don’t think it’s difficult to do that, but to your point, I’m not sure how much security it’s really giving you. But then there is that other topic, Ayush that you went into, which is also a huge one about headless WordPress and WordPress can be used as a headless CMS. And we talked earlier about the REST API for instance, which is one thing you’d leverage in order to do a headless architecture. And just to ask one more question about that setup, is that necessarily more secure than traditional WordPress?

Ayush Malakar:

So the way architecture works, it does so show that it adds the security of WordPress website just because how the architecture is laid out. Because whenever we are working with a standard WordPress website, the way the connection works is once you hit the page, it makes query to the database, then the page templates, and you’re pulling all those contents in. So you’re always needing to make that one added connection to the backend.

Now with a headless CMS, it’s completely different. So in that architecture, how it works is the backend is separate and the front end is separate. And the way the content is pumped, like I mentioned before, is we had the REST API. And once the content has been pumped in to the static side generator, the static side generator doesn’t need to constantly ping the WordPress back in to pull in content. So it also helps you in terms of performance and also adds an added layer of security because we don’t know where the WordPress lives. All we can see is the content. So in a way it does add security benefits.

Tess:

Anything else that you wanted to add on that one, Sean?

Sean O’Shaughnessy:

Yeah, same. I think though at the end of the day, still don’t let your guard down when it comes to the WordPress side of that. You’ve got that WordPress application somewhere. It’s providing that content via API to that decoupled application. That doesn’t mean we could ignore it because it’s now sitting behind a different URL structure that’s not easily used to surmise or guess where the application is. So still be just as diligent in how you approach that application. Doing everything we’ve talked about here today for sure.

Tess:

Cool. We’ve got so many questions coming in, they’re really good as well. So we might need to go a bit more rapid fire. So Sean, would you add your plugin updates directly in the WP dashboard or would you also pass those through version control?

Sean O’Shaughnessy:

Version control only.

Tess:

Everything through version control.

Sean O’Shaughnessy:

Everything through version control, yes. Huge fan of it. And again, having that layer in place and having different environments, I’m not going to be surprised by clicking an update button within the admin, but I understand that needs are different. The type of approach and receptiveness I would have to updating plugins in the dashboard is going to be very different from my, let’s just say personal recipe site than it will be for an enterprise customer’s application.

Tess:

Can you share the link to your personal recipe site for everyone? We would like to cook your recipes, Sean, so we can just add that later.

Sean O’Shaughnessy:

No, it’s easy stuff. It’s like grilled cheese, chicken fingers. There’s nothing complex about it.

Tess:

Are there certain levels or types of logging that you would recommend monitoring to catch any security issues as quickly as possible? Ayush, do you want to take that one or Sean? Whoever would like to jump in.

Ayush Malakar:

Sean, if that’s okay.

Sean O’Shaughnessy:

I’ll give it back to you. No. Yeah. I would say start at the top. Understanding the access level logs that come into your application where traffic is coming from. Look for things like specifically HTP post or put request, depending on the underlying functionality. Those are obviously easy to filter and stick out, but usually you should see these things against your login endpoints from legitimate users of the application. If you’re seeing a lot of that traffic, you may need to look at things like brute force detection and mitigation. How can we maybe stop some script or bot from running through a dictionary of passwords early and just block and shed that traffic immediately?

And then I would add within that there’s different and interesting things one can do around audit logging, having a full accounting of who published a post, who changed a post when a user was added. And then once you start gathering and collecting this data, then you can do very interesting things like now let’s monitor for the things that are interesting to us within the types of events we’re seeing.

Tess:

Cool. Yeah, there’s a really good follow on question to this actually, which is any specific tools you would recommend for log analysis and monitoring?

Ayush Malakar:

Yeah, I can take that one. So it depends on what we are trying to log up. Primarily what I’ve seen is depending on your host, they take care of everything like Sean mentioned. Seeing the points where people are coming in, who are trying to access your websites, all of those. But if we do need some additional login, we can also try to do user activity login. We can also try to check the history of whoever’s come in, whoever’s gone out, how many people access the website, what the pattern is, how many frequently IPs are working. So for those I would recommend using security. And even the WP security audit, user login audit, there are plenty of tools available. It’s just a matter of figuring out what works best for your application.

Tess:

Cool. And the next question is also related to that. I’m not sure if there’s, it’s the same or if there’s anything else to add, but what are your recommendations for application performance monitoring and being proactive on finding issues security related or otherwise?

Sean O’Shaughnessy:

And I would maybe separate application performance monitoring from all the things we talked about around security and audit logging. To me anyway, application performance monitoring is how the application is performing. We have a suboptimal or underperformed query. Are we waiting on some external integration for too long to provide a response that we then parse and put into our application? And I think the sort of leader in this space right now is are folks like New Relic, Datadog who are providing and surfacing those tools and the dashboards that make getting into the code and where it’s having these slowdowns very useful. But I don’t know, do you use other tools or those familiar?

Ayush Malakar:

So for performance, it’s mostly on the hosting to see how it’s working, what this memory is. So if there’s any queries that taking up a lot of memories and optimizing them. But at the same time, for security related issues and trying to figure out if a plugin has vulnerability or not. So we heavily rely on WP scan as I mentioned earlier, that tool is really great to understand whether or not the current versions of the applications we are using have any potential vulnerabilities in them.

But other than that, just being proactive as the site owner and if you’re a developer, using the tools that I mentioned previously to ensure that the code that we write or the code that is written for the application does not introduce any vulnerabilities. But if they are found using version control to either go back to a previously known version which does not have that vulnerability or maybe even putting things on hold and trying to do a quick hot fix.

Tess:

Okay. Next question. Any specific advice for a WP multi-site incident?

Ayush Malakar:

I’ve used a fair bit of WP multi-site and for the most part WP multi-sites are used for resource sharing. And if you do have a WP, I would just echo, just be more vigilant. And whenever we use the teams or plugins, some of those might not be multi-site compatible. And even if they are, they might have different instruction on how we can utilize them, but at the end of the day, it’s sharing resources across different WP incident and I think it also falls back on the host and doing our due diligence on a very high level.

Sean O’Shaughnessy:

Yeah, for sure.

Tess:

And I guess another thing is access.

Sean O’Shaughnessy:

What’s that?

Tess:

Sean, did you want to… I was just going to say access as well maybe.

Sean O’Shaughnessy:

Yeah, and I think a great reason to reach for multi-site is that we have a lot of sites that will mostly look the same, function, the same or can benefit from a single shared code base. Because now we’re keeping that attack surface for any sort of potential issues small. We’re not spreading it out across a bunch of different installs that have any varying number of different plug-ins and themes. But within that, like you said, the flip side of that is that should something bad happen, it’s a little bit more difficult to contain that within just a single site within the multi-site install. Additional steps and thoughts and things like that are needed for sure.

Tess:

Okay. Well we just have time for one more question, which ties a little bow on the whole session. So I’m a fan of that. If you could do only one thing to make a WordPress website more secure, what would it be?

Ayush Malakar:

But that’s a great question and a hard one to answer honestly because I doubt there’s just one thing that you can do. But if I had to point it out, I would just be, would say be more diligent in and understand just software as a whole. And understanding that even if you do not have any technical knowledge, there are still tools available out there to help you understand there might be potential vulnerabilities within some of the plugins that you use on some of the themes. So just be more vigilant.

Tess:

Sean?

Sean O’Shaughnessy:

One thing? You’re going to make me pick one thing?

Tess:

One thing.

Sean O’Shaughnessy:

Just one thing.

Tess:

Yeah, one thing.

Sean O’Shaughnessy:

Tough call. I would say probably starting at root force detection and mitigation.

Tess:

Okay. There you have it. Thank you again so much everyone for joining. Thank you to Sean and Ayush as our experts for this session and we will see you soon. Bye everyone.

Sean O’Shaughnessy:

Thank you, Tess.

Ayush Malakar:

Bye everyone. Thank you Tess.

Tess:

Thanks.

Ayush Malakar:

See you, everyone.