The Drupal community puts a lot of attention into security. Drupal’s security team is the main party that is dealing with security issues and reports. They are monitoring all modules with stable releases that are published on drupal.org. This is one of the many reasons why we strongly recommend all our clients to publish their custom modules or 3rd integration plugins through it.
Another way of ensuring high security standards are APIs that automatically ensure security when used correctly and a set of best practices that should be followed in order to write secure code. The Relevant section of the Drupal 8 documentation provides more information on that. The similar document for Drupal 7 is also relevant, since a lot of things stayed the same since then.
MD Systems is strictly following all recommendations and best practices that the community developed. Even more, since we are one of the biggest contributors in the Drupal community we’re actively taking part in their further development and advancements. We are also using automated tools that can detect some of the security vulnerabilities in the code.
In this series of blog posts we’ll explain some of the most common vulnerabilities on the web and how Drupal secures against them. This time we’re covering XSS, which is probably the most common vulnerability on the internet.
Cross Site Scripting (XSS)
Drupal’s general approach to the unsecure user-submitted content is escaping at the display time. This means that we generally consider any content that came from the internal database or from any 3rd party system as potentially malicious.
Drupal 7 relied on developers to properly escape the content before displaying them (using functions like check_plain() and filter_xss()). Useful and easy to use API functions made writing secure code easy, but still prone to human errors.
Drupal 8 made a huge step forward in this areas. In order to secure the system against XSS it automatically escapes all variables that are printed as part of the Twig-powered template system. This means that we’re providing substantial protection against XSS attacks by correctly using provided render APIs.
Our naughty editor now expects an alert popup to appear when the article is visited. But Drupal 8 is smarter. It escapes the malicious code which results in it being displayed to the entire universe. Not pretty, but definitely secure. The bad intentions of our naughty content author are immediately revealed.
Drupal: 1, Hackers: 0