I’ve appreciated the recent member email notices about the increasing threats against open source CMS and site builders that can expose database and system vulnerabilities, like Wordpress, Backdrop, Drupal, CiviCRM, and Joomla.
I was curious if we know of any existing best practices for each of these systems to mitigate these threats. It seems that static site generation if available, may generally be the simplest and most powerful strategy. If static generation is not feasible or possible, then a decoupled or headless system with a firewall requires potentially more effort but would also offer greatly enhanced security.
A cursory web search shows me a number of static site generation plugins for Wordpress and one for Drupal 9+, and in the other cases there are built-in web services/API extensions available for Backdrop, Joomla, and CiviCRM.
Do any May First members have experience in any of these mitigation paths? Are there any recommended guides to setting up HTTP basic authentication on a May First hosted site, or other ways to firewall a May First CMS backend?
Hi Oren, I recently put together this guide for using the SimplyStatic plugin with wordpress.
It also includes the steps for setting up http authentication to protect the wordpress install folder. I’ve helped a few members implement this and it seems to work well.
I administer a few Backdrop and CiviCRM standalone instances on May First.
In the case of Backdrop, it seems that there isn’t a static site generator module, and since most pages are intended for unauthenticated site visitors, decoupling would be the way to go, possibly foregoing Backdrop’s layout and theme configuration.
Does May First support Apache setenvif? In the case of CiviCRM standalone where most of the pages are for admins only, could this be used to set up a few exceptions (like user-facing forms), while protecting all other site pages with HTTP basic auth?
For security reason, we list the Apache directives that are allowed, rather than the ones that are not allowed, so anything not allowed is simply not something we’ve been asked to add before. Happy to add SetEnvIf if that would help.
Also there might be easier ways to allow some directories but not others?
I’ve seen these terms all used somewhat interchangeably. In this context, “decoupling” means that there are two separate systems: a backend where only admins log in and still experience the same content authoring workflows, and a frontend which is any static site generator that updates the static site, usually through a web service / API call.
After a bit more searching, I see that CiviCRM has it’s own documentation about using it behind a firewall, and an extension (CiviProxy) for the use case I described, of whitelisting user-facing forms but protecting everything else.