Drupal Mistakes: #2 Security

Good security practices protect your site from hacker attacks. In this article we'll look at some methods for reducing security risks on your site.

Drupal Security Best Practices

Drupal has good security built in if used correctly. However, once you begin to configure your site you might introduce new security issues. Plan configuration so that only trusted users have permissions that involve security risks.

Keep core and contrib modules updated

You may not opt to do some module updates if the fixes or improvements have no direct effect on your site, however you should always apply security updates as soon as possible. Subscribe to security announcements on Drupal.org.

Use Strong Passwords

Passwords are the most likely candidates for points of failure in your site security. Use the Password Policy module to devise a set of constraints before your users can set their passwords. You can also set a password expiration.

Limit file uploads and limit what files are served

Limit allowed file types and limit uploads to trusted users only. Check your permissions for specific content types, and files types allowed in field uploads.

Use the Security Review module

The Security Review module will analyze your site configuration and report methods for fixing errors. Only use this module on a staging or test site. Disable and remove the module on production sites.

Guard against attacks in custom code

Following are three attacks to guard against in custom code in your themes and modules.

Avoid: SQL injection

Mistake: Using SQL queries in code rather than using Drupal API.

Example: The code db_query("select * from table where id=$_GET[‘id']"); allows for the attack example .com/index .php?id=1 union select * from users;

Solution: Use Drupal's database abstraction layer. [See http://api.drupal.org/api/drupal/includes%21database%21database.inc/group/database/7]

Avoid: XSSCross-site scripting

Mistake: Displaying visitor parameters without checking them allows visitors to inject client-side scripts into pages viewed by other users.

Example: The code allows the attack Index.php?id=

Solution: Clean (sanitize or filter) and input from untrusted users before returning to the browser for render.

Avoid: CSRFCross-site request forgery

Mistake: URLs containing wildcards (%) that are not protected and form code entered directly into the site. HTTP Post from forms can allow a request to originate from anywhere, not just your site as you expect.

Solution: Use Drupal's Form API, which protects against these attacks by inserting a token in every form. If you render any sort of URL that should be protected, make sure that you either ask for a confirmation with the Form API or use a token with the URL and verify that the token is present and valid on the response handling. Read more here: Introduction to cross-site request forgery.

Learn how to become a Drupal security expert in Acquia's Library!