Stay Safe With Drupal

A lot of the time during exciting conversations about Drupal with people thinking to build their application in Drupal, we arrive at the subject of security. How secure is Drupal, what sort of guarantees do I have that my content is safe, is the such and such platform or cms a better option for me in terms of security? Granted security is a very important topic, one that could do with a bit of elaboration.

All web applications, to a degree, have the potential to be insecure, in fact, until you discover that an application is insecure, you have no real way of knowing. So there are two ways you could really go about it; you could write your application, keeping to the common best practices, and hope as your application scales up that nothing is exploited and that coding standard is continually adhered to. Alternatively, you could employ a dedicated team who can look over your code, run audits against new code being released into the wild including all existing code, run tests against it, try to break it and address things before they pop up or after they pop up. But who can afford a dedicated security team for this? Well luckily, Drupal has its own security team, that means whenever Drupal’s security team decides to implement security fixes or address potential exploits or issues, you can get notified and have access to the new patches. A lot of the time when someone has an application developed for them in a lighter framework or a cms that don’t necessarily have such a team overseeing the security side of things, you can end up having security holes in your site without even knowing it until something goes wrong, and by then, it can sometimes be like trying to find a leak in a flooded room. Fortunately, when an update arrives, you have access to it, and there’s comfort in seeing a list of modules including Drupal core with green ticks next to it, saying that it’s all up to date with the latest security patches.

Not only this, but vast swathes of community modules also have security checks over them, and you can tell if a module has had the all clear on it denoted by a shield icon on the download link of the module page.

Of course, however, your site won’t just be using the latest security patched Drupal core, nor only the latest security patched community modules, but sooner or later you will also have your own modules delivering application-specific functionality across your site to you and your user base. Fortunately again, provided your Drupal developer is adhering to Drupal code standard, the Drupal code library functions already have security in mind built into it and functions available that can ensure that you are developing in line with this standard.

There are, of course, many more things that can be implemented to keep your application secure, so let’s list out the following commonly used apps and solutions that can be used, and then elaborate on them some more, note that this list is by no means exhaustive.

• Security Kit

• LDAP

• User Permissions & Roles

• Password Protection Policy

• Captcha & Honeypot

• Cloudflare protection

• HTTPS

Security Kit

A popular community module that can be used is the Security Kit. Security Kit is available for both Drupal 7 and Drupal 8. It is comprised of a suite of tools geared toward preventing Cross-site Scripting, forgery attempts, clickjacking, SSL/TLS exploits among others. The excellent thing about Security Kit is that it is customizable, you can really tighten up a site and lock it down, so much so that you could actually make your site unfunctional if you go too far. This is really excellent for making sure your application is only running scripts that you allow it to.

LDAP

Chances are you’re familiar with LDAP, but if you’re not, LDAP allows for centralized user management, which is critical when an organization needs to give access to multiple employees across multiple different servers or applications. Without a centralized place to do this in, it would become exceedingly awkward to go through each server and app and grant individual access to one or multiple users, including password changes, removing users, restricting or granting more privileges.  Luckily Drupal has LDAP support, allowing the web app to authenticate to an LDAP server, meaning if a user is removed from the centralized server, they will no longer have access to Drupal. Likewise, if a password is changed, it will be changed for Drupal too. This is really important when there are old accounts out in the wild waiting to be logged into by an ex-employee or would be a hacker. If you have a lot of users across a wide net of different places, chances are you’re using LDAP. Good news, Drupal has LDAP too.

User Permissions & Roles

As your application grows and scales and you add more employees and departments to your company, sooner or later you’re going to want to start putting restrictions in place. For instance, maybe you don’t want content creators being able to release changes without going through an approval process, and maybe you don’t want editors creating content either. Drupal allows granular management over all sorts of permissions; modifying, creating, removing specific content types, access to certain pages, widgets and functionality. With this, you can have peace of mind knowing that not every user in your system, especially your customers or anyone wondering off of the world wide web, will have access to every far-reaching branch of your web application.

Password Protection Policy

Sometimes being hacked can boil down to something as basic as having a poor password or password policy in check. Forcing users to create something that will give a hacker a hard time is a lot better than allowing a password to have a password like “password123”, “egg”, “bread”, “soup" or “peanut”, much better to combine them all into something like “egg bread peanut soup”. Drupal will allow you to customize the policy, meaning your accountant looking to get a hold of the numbers won’t be able to just type “money” in as their password, giving you both peace of mind that someone, it’s going to guess that or run a password cracker in and log in, which leads me onto our next security feature; Captchas and Honeypots.

Captcha & Honeypot

Nearly all clients will ask for Captcha, most who have had a web app with a client facing form are aware of spam, have confronted it and possibly fell victim to it at some point or another. Drupal has modules to handle traditional Captcha, but also Google’s reCaptcha and options to extend and add other forms of Captcha also. This can prevent things like users being spam created, or multiple sign-in attempts when trying to crack a password. Another useful feature, which can help prevent the need of an ugly web Captcha on every form, is to use the Honeypot module. This is commonly used and adds hidden elements to your form to trick bots and script attacks against forms, and a surprisingly high success rate, allowing you to really cut away the spam from your forms.

Cloudflare Protection

Cloudflare, along with other platforms offering similar services, is very useful for determining right out of the gate if a visitor is malicious or not. You might have seen something like this before when visiting some of your favourite sites, before the initial page loads, a small cloud icon appearing in the center of the page and a countdown to check whether or not you might be a bot or coming from a known malicious IP address. The prime intent is to prevent denial of service attacks. Cloudflare comes at the cost of a subscription fee, and might not be necessary for many people, but for some people wanting to throw up a good wall of defence when having previously suffered many times from DOS attacks, without necessarily wanting to dig too much into the cause or other forms of prevention, Cloudflare may be an excellent choice.

HTTPS

A more obvious one, if not necessarily one if you’re offering the creation of user accounts and facilitating transactions or storing client sensitive data, is the use of HTTPS. If you’re doing anything other than showcasing a few pages and a portfolio, you should definitely be using HTTPS. This involves setting up a certificate that can be bought from the same places you buy your domains from. If you use Pantheon or Acquia, the procedure is pretty painless, but as always you should look to a professional to assist in setting this up. Once set up, you can be at rest knowing that your transactions and page views are all being encrypted, and some guy in a cafe next to you isn’t creeping your web traffic over the wifi as you log in to administer your web app. Food for thought!

Hopefully, you found this helpful, the list here isn’t exhaustive but should shed some light on some basics that you can implement on your next web app or existing one, to help keep things nice and safe. As always though, talking to a professional is best for a more tailored experience to figure out what you actually need, and what you don’t.