5 Most Critical Security Risks on Drupal 8
Drupal is said to be the most secure CMF out of the most well known ones (Drupal itself, Wordpress and Joomla!).
If you are interested in the difference between Drupal and Wordpress, you can read more here. It’s secure enough to be the framework on which the White House’s site is built, which says a lot!
But nothing is perfect, and Drupal has some serious vulnerabilities that can cause great damage, if you are not careful.
Today Drupal help team is going to list 5 of the most critical website security risks on Drupal 8, in order to make sure that you’re aware of every possible danger and that you know how to avoid it.
Drupal 8’s Security Risks
Cross Site Scripting (XSS)
XSS is a typical computer security vulnerability that is usually found in web applications. It allows hackers to inject client-side scripts into web-pages. It works like this: a user enters some page where malicious code was injected, and this code immediately attacks user’s computer.
That’s why it’s important to remember that you should give access to the full HTML code of your site to the trusted users only.
Fortunately, now there is the Twig templating engine in Drupal 8 that sanitizes all of the variables by default, but keep in mind that XSS does exist.
SQL Injection
SQL Injection is a widespread code injection technique in which a nefarious SQL code is inserted into a query. With the help of the SQL Injections, hackers can get a full access to the system’s data to destroy it and even to become administrators. That’s why you should remember not to use unsafe data in a database query without clearing it. This Drupal 7 function is now obsolete in the 8th version, though it’s still available to make sure that legacy code is working as needed.
Also, there is no need to use this function, as the object-oriented method of building a query is available now in Drupal 8.
Cross Site Request Forgery (CSRF)
Cross Site Request Forgery is a type of attack that takes advantage of the vulnerabilities of the HTTP. It usually goes like this: when a user enters a site that was created by a hacker, a query is sent on their behalf to the totally different server to perform some injurious action (e.g. transfer money to a trespasser’s account).
Concerning Drupal, the action can be, for example, to delete some kind of content on a site. In that case the confirmation form pops-up (“Are you sure you want to delete..?”) and that usually prevents the attack to be successful. That’s why it’s really important to have such forms for every important operation and to make sure that the site’s HTML is accessible only for the chosen ones.
Authentications and sessions
There are some other things you should also keep in mind. These are weak password storage and account management, session hijacking/fixation and lack of session timeout/logout. It doesn’t mean that Drupal has no solution to prevent those things from happening. Drupal 8 stores passwords and user’s session data in hashed form, which means that the chance for that data to be hijacked is minimal.
Avoiding updates
Last but not least, you should understand that the only way to protect your site and personal data is to update Drupal’s modules and core. Drupal Security Team is constantly fixing different bugs and flaws that can be dangerous for your page. So it seems perfectly reasonable to update everything and to make sure that your site is armed and protected :) You can read more about the risks of avoiding Drupal updates here.
Conclusion
Now you are aware of most of the security risks on Drupal 8. Don’t be afraid though — to be forewarned is to be forearmed. The sky is the limit, and Drupal is doing everything possible to protect the sites of its users. So don’t be afraid to lean on Drupal security, it won’t fail you!