Why Drupal 8 is a Secure Way to Go for Web Development

November 2015 introduced to us Drupal 8, the biggest update to Drupal to date. Anyone who supports online content should make allowance for Drupal 8, one among the world’s most well developed open source content management and digital experience platforms.

Drupal 8 is fast and secure, and fosters the process of website development. Every organization, whether small or large – including NGOs, global enterprises, colleges, or brands – uses Drupal to deliver relevant content in real time and improve user engagement.With the latest version of Drupal come high security features that help overcome any security risks and ensure business security in the long run. Owing to its advanced features, it proves to be an ideal platform for new projects. Explained below is every good reason why you can trust Drupal 8 security.

Twig for Template Engine

Drupal 8 comes with Twig, a template engine that helps override all templates which are used to produce HTML markup. Twig allows you to completely customize the template of your choice to see a markup of your choice.

Twig is an advanced form of PHP template that was developed in-house by developers. It has templates for every single element on a page.Twig was created by SensioLabs. Supported by Symfony2, it becomes a preferred choice to use for Drupal themes.

Below is the comparison of two snippets from Bartik theme in Drupal 7 and Drupal 8. Both the snippets function identically.

This is a snippet in Drupal 7 and the node.tpl.php document:

<?php print render($title_prefix); ?>
<?php if (!$page): ?>
<h2<?php print $title_attributes; ?>>
<a href=”<?php print $node_url; ?>”><?php print $title; ?></a>
</h2>
<?php endif; ?>
<?php print render($title_suffix); ?>

This is a snippet in Drupal 8 and the new node.html.twig document:

{{ title_prefix }}
{% if not page %}
<h2{{ title_attributes }}>
<a href=”/{{ node_url }}”>{{ label }}</a>
</h2>
{% endif %}
{{ title_suffix }}

Javascript API incompatible with Content Security Policy

With drupalSettings having conventionally been loaded through inline Javascript, Drupal 8 needed removal of all inline Javascript to support a Content Security Policy (CSP). So the Drupal render API had support for inline Javascript removed from the #attached property. Drupal Javascript settings variables are no longer put as inline Javascript. Rather, these are added as JSON data to the page, which ensures compatibility with CSP, implying mitigation of cross-site scripting (XSS) vulnerabilities and respect for per-site restrictions.

Improved user session and session ID handling

Drupal 8 features improved user session and session cookie handling in different ways:

• Session IDs have been made more secure against exposure using database backups or SQL injection. Earlier, session ID was tracked directly against incoming session cookie from the browser, which risked population of cookie from database value and assumption of any user’s session and identity in case they had a valid session in the database. Additionally, the ID is hashed before storage in Drupal 8. This helps prevent user’s session assumption using database value.

• Mixed-mode SSL session support has been removed from core. Basically, it was introduced to support sites which had contributed modules to serve the login page over SSL and to keep other pages unencrypted.

Portable configuration

YAML is used as the export and import format by Configuration Management Initiative (CMI). These YAML files are manageable together with your code and can be and tracked into a revision control system (git, for instance). This enhances Drupal 8 security as PHP code is not used as an import format and acquiring history of configuration changes becomes much easier with configuration tracking in code. Drupal becomes compatible for enterprises which require stringent controls on configuration changes.

In the latest version of Drupal, you can check configuration in development and replicate it to production as well. This helps prevent any errors during manual configuration. The result? You absolutely do not need to make any configuration changes in production for forced deployment of changes in the form of code.

Route definitions protected against CSRF token

Ideally, it is essential to safeguard links or GET requests that result in some disastrous change against CSRF. To ensure this, a user-specific token is required in the query string, which is evaluated before proceeding with the action. Automation of the process leads to improved developer experience and increased security. Code centralization makes the audit easier while also providing test coverage.

With Drupal 8, the process becomes much easier. It doesn’t require the developer to specify a CSRF token for a route.

Take a look at this YAML route definition for a protected link in Drupal 8 entity.

entity.shortcut.link_delete_inline:
 path: ‘/admin/config/user-interface/shortcut/link/{shortcut}/delete-inline’
 defaults:
_controller: ‘Drupal\shortcut\Controller\ShortcutController::deleteShortcutLinkInline’
 requirements:
_entity_access: ‘shortcut.delete’
_csrf_token: ‘TRUE’

Trusted host mechanism support for requests

A number of Drupal websites use a random host header communicated to the correct IP address to respond to a page request. This raises risks for cache poisoning, forged password recovery links, sham site emails, and other security-related issues.

All the previous versions of Drupal made it challenging to properly configure the web server for a website that prevents such DNS spoofing attacks by using sites as its site directory. However, Drupal 8 allows to configure predicted host mechanisms in settings.php. It even sends you a warning in site status report in case you forget to configure it.

Power your digital presence with Drupal