Webdrips Drupal 8 Demo site: why Drupal 8 is More Secure than Ever Hero Image
2019-02-14

Why Drupal 8 is the Most Secure Version to Date

Drupal 8 is by far the most secure release of Drupal to date. We'll list twelve reasons why, but most of them may not mean much to non developers, so we we'll just touch on each reason at a high level.

1: Drupal 8 Core has far more Crucial Built-in Functionality than Prior Versions

This is crucial to website security because core modules have a much higher level of scrutiny than community contributed modules do. Being in core means passing a much stricter review process before being added, and with many more eyeballs on the code. Also, unlike some contributed modules, Drupal core updates are released regularly.

What is a Module? Drupal Modules provide plug-and-play features and functionality. Typically you can enable and configure them to make their feature and/or function available. Drupal has core modules that "ship" with Drupal, and nearly 7,000 contributed modules available for Drupal 8. Contributed modules are modules added and maintained by the Drupal community.

2: Drupal 8 is Built on top of the Symfony PHP Framework

Drupal 8 has gone away from the Drupal-specific frameworks, and adopted the Symfony Framework instead. Since the Symfony Framework is used by over 20 CMS platforms (including WordPress, Craft, and Joomla), there are exponentially more eyeballs working with the core framework. That means more people are available to find and fix security holes. 

3: Twig Templates Enforce Greater Decoupling and is More Secure than PHPTemplate (Drupal 7 and Prior)

Twig provides much stricter separation of business logic and presentation (design). For example, you can't run SQL queries or other arbitrary PHP code in a Twig template. Drupal 8 also enables Twig auto-escaping, so unless a string is specifically flagged as safe, it will be sanitized. 

4: The PHP Input Filter has Been Removed, and the Configuration Layer Doesn't Allow PHP

The PHP Input Filter allowed anyone with permission to add PHP to a block, page, etc. This had always been considered a bad practice, and is no longer available unless you download a contributed module.

5: Site Configuration is no Longer in PHP

Drupal 8 uses Yaml to define configuration instead of PHP, so not only is it safer, it's much more readable, and easier to compare differences. This is also true of configuration imports, like moving views between sites. 

6: Improved Editor Content Entry Mechanism and Filtering

Drupal 8 ships with the CKEditor editor, which provides a WYSIWYG experience much like Google Docs or Microsoft Word. Not only was this a huge usability boost, the use of "Full HTML" is now highly discouraged, and "Filtered HTML" is now the default. The use of "Full HTML" often opened your site up to Cross-site Scripting (XSS) attacks. You may also set a filter to only allow local images, which helps prevent Cross-site Request Forgery (CSRF) attacks, among others.

7: Hardened User Sessions and Session ID Handling

The security of session IDs (which could be used to hack a site) has greatly improved by reducing the possibility of exposure. Mixed-mode SSL session support has also been removed. Given most browsers now warn for any webpage not using https, this was the right move. Finally, the subdomain (e.g. www) is no longer stripped from the "cookie" domain (causing the session cookie to be sent to all subdomains, which was bad). 

8: Automatic Cross-site Request Forgery Token Protection in Route Definitions (i.e. paths or URIs)

Now unique tokens are added to "destructive" route definitions provided via links, which protects against CSRF attacks. The change helps developers who might otherwise forget to make such checks.

9: Trusted Host Patterns were added to all Requests

Older Drupal sites would respond to a page request using an arbitrary host header sent to the correct IP address. This could allow for bogus site emails, bogus password recovery links, and other security-related issues.

10: MySQL (via PDO) now Limited to Executing Single Statements

"Drupalgeddon" is, to this day, the worst Drupal security hole ever discovered. It involved a SQL injection vulnerability that was easily exploitable by anonymous users. (It was so easy to exploit, attacks were happening within an hour of the security patch in Drupal 7 that addressed it.) 

Drupal 8 now sets a flag that limits PHP to only sending a single SQL statement at a time to the MySQL database. This update has now been ported to other database drivers.

11: Clickjacking Protection Enabled by Default

Drupal 8 now sends something called "X-Frame-Options" SAMEORIGIN in all header responses by default. Most browsers respect this setting, which prevents sites from being served inside an iframe on another domain, which allowed for click-jacking attacks.  

12: Core JavaScript API now Compatible with Strict Content Security Policy (CSP)

CSP provides a new standard to communicate per-site restrictions to browsers, which mitigates XSS vulnerabilities, among others. 

Conclusion

There are at least twelve reasons why Drupal 8 is more secure than Drupal 7 and prior versions (although some of these items mentioned have been back-ported). 

Drupal 7 site owners should be aware of the recent end-of-life (EOL) announcement and what it means to your organization. 

If you're still using Drupal 6, although critical security patches are still being offered through the long term support program, keep in mind substantially fewer people are working on Drupal 6. Have a look at this blog post for more information.

If security is a concern to your organization (as it should be), now is the time to upgrade to Drupal 8.

Image
Webdrips Drupal 8 Demo site: why Drupal 8 is More Secure than Ever Hero Image