There is a common misconception about open-source software and security.
The thought is that because the software’s code is out in the open, it makes it less secure than proprietary software and more vulnerable to hackers.
The reality, though, is completely opposite.
- Yes, everything about an open-source platform like Drupal is out in the open. But what that means is that there are always many people looking at the code. Sure, anybody could try and hack it, but anybody can also protect it. That’s why, in general, open-source systems are more secure than their proprietary counterparts.
Drupal has a good track record when it comes to addressing security issues. Whenever there is a security concern, there is a bulletin released and there are updates to fix the problem. On top of that, there is a dedicated Drupal security team that works to find potential security risks.
Even with all of those precautions, some Drupal users prefer to have even more security in place than what Drupal offers out of the box. In that case, I recommend the Security Kit module as a way to further protect your website and users.
Security Kit adds additional security-hardening options to Drupal. However, it is important to note that some of the provided security options are not supported by all browsers (learn more here). I recommend only enabling these features if you are an advanced user.
So, what makes Security Kit such a great module? Here are four security challenges you can avoid by using the module:
- Cross-site Scripting by defining Content Security Policy
Adding security policy will help prevent cross-site scripting because it allows you to specify that user’s browser is only allowed to load assets, java scripts and css from specific domains, such as the website’s own domain. Any assets referenced from sources other than trusted domains you have listed would not show up or render on the webpage.
- Cross-site Request Forgery via Handling of Origin HTTP request header
This option allows for checking and comparing the origin HTTP request header with target. For example, let’s say you have a form to submit on your website. The application will be required to verify that when someone goes to submit that form, the submission originated from your domain via Origin HTTP header. If a web application senses that a form is coming from somewhere other than your domain — like through a third-party location — it can prevent the form from being submitted.
- Clickjacking via Implementation of X-Frame-Options HTTP response header
Clickjacking, in its most basic form, means that a hacker can display a page, or even just a component of a page, like a button, in an iframe. This enables the hacker to deceive the user, and can potentially lead the user to click a link or a button on a targeted website. Security Kit gives you the option to not allow your website to be displayed in an iframe, thereby preventing clickjacking via iframe.
- Man-in-the-middle and eavesdropping attacks via Implementation of HTTP Strict Transport Security (HSTS) response header
This functionality is focused on ensuring that your website can only be accessed through HTTPS. All communications between your browser and an HTTPS website are encrypted. Now even if you have your website set up to use HTTPS, there may be portions of the site that are still accessible via plain HTTP. Since traffic sent using HTTP is not encrypted and is in plain text, it is susceptible to eavesdropping. Enabling Strict-Transport-Security HTTP response header functionality forces browser to connect to the server in HTTPS-mode only and automatically convert any HTTP request to HTTPS.
As you can tell, these features can be pretty complex, and misconfigured elements can break your website.
Let me reiterate that Drupal is a very secure platform, but if you’re looking for that next level of security, consider the Security Kit module. It will keep you, your website and your users secure.