The things we found in your site - part 2
by Hernani Borges de Freitas
Today I want to cover a couple of more topics that can affect the life of your website and cause pain in its normal operation.
Drupal has proven to be one of the most secure tools to build websites. The fact that it has been used by governments, media companies and important NGOs in the world is the best proof of this fact. Drupal has a security team that looks to Drupal core code and stable releases of contributed modules and helps in the process of coordinating security fixes.
Most of the major security problems that we found in clients websites are not due to bad code but erroneous configurations.
- Regular users have permissions to do things that they should not be able to do. This includes access configuration settings, input malicious HTML, and upload all types of files.
- Privileged users have easy passwords, similar to usernames, for instance.
- Processes that interact with Drupal like Webservices, Memcache, ApacheSolr are not protected. When thinking about protecting your Drupal site, think also in everything that it connects to and guarantee those processes are also safe.
- Security review moduleis a great checkup tool, which can detect a set of common basic problems regarding security.
The most usual problems in custom code are due to:
- Input from users not being correctly validated leading to cross site scripting (XSS) attacks. Drupal has a good set of sanitization functions that should be used whenever you are dealing with input).
- SQL injection problems: Drupal DB API protects you from this type of attack as long as you are not using it correctly).
- Cross site request forgery, which is a relatively unknown type of attack to web applications and can be avoided if the form API is used correctly and sensitive urls are token-protected.
Most of talks regarding web performance seem to miss the most essential point. Before jumping to optimize different parts of your application/server stack,you need to get the most essential bit of performance optimization: you need to have data. Statistics about page rendering times of your application, resource consumption on the servers and most important application profiling information are fundamental to understand what is the problem.
XhProf is a powerful profiler that can give you an insight about what is being done by your application. It can be used with Drupal using the XhProf module in Drupal 7 or devel module in Drupal 6. NewRelic, a product part of the Acquia Network, can give you extra insights about all the pages in your site. It can be a life saver to detect problems that only occur in certain occasions and its data can provide a confirmation that your changes are introducing improvements to your site.
Tipically the most common problems we find regarding performance are due to:
- Complex database queries that take too much time.
- Expensive functions that are called too many times or in situations where they are not recommended (hook_init and hook_boot are used too often).
- Edge case situations that are happening all the time (cache being cleared, theme being rebuilt).
- Expensive displays that are rendered in all pages (mini panels as mega menus, menus with a large number of items, displays that will consume information from slow data sources like slow webservices and databases).
- - Caching strategies badly designed. My previous blog posts can help you fixing those ones.
Again, the best way to understand the bad performance of your site is looking to what your profiling data is telling you. An average normal authenticated page in Drupal should not take more than 30~50Mb of memory and 1~1,5seconds to render, if it is taking more than that you should profile it to understand if you can optimize some parts.
This is where your site lives, so it is important to be correctly sized and tuned. The most important thing that I usually recommend to my clients is to understand some basic configuration of different parts of a normal stack used to host Drupal:
- APC is probably the first PHP extension that you want to have installed when serving Drupal: increase its memory limit to handle most of Drupal codebase without the need to reload it from disk in each page request is extremely important.
- Understanding server limits in each part of the stack depends not only of resources available but complexity of your application. You will probably need to load test and benchmark your application, before you can have a real feeling on how it is going to behave.
- Mytuner.pl can help you configuring the right limits to your MySql server.
- There are better ways to handle caching, searching and logging in Drupal than using the default database backend. Explore them!
By maintenance I refer to all the daily/weekly/monthly tasks that you will need to perform on your Drupal site. There are a couple of things that we keep seeing in different projects, unfortunately:
- Missing staging environments where changes can be tested and problems can be debugged. Some other times we see staging environments completely different from production or that hard to synchronize with production. If you can't replicate in your staging environment what you see in production, its value is null. You will need a staging environment to test upgrades to your site, changes introduced in code and configuration before you move it to production.
- Code development and deployment not using a version control system. It does not mind which one you choose (even if Drupal community relies mostly in Git these days), but you want to control the changes occurred in your code and you want to guarantee that code that is deployed can be traced back in time.
- Lack of access to the different environments in order to move things quickly from production to development environments and missing deployment processes, which allow deploying new features to production in a safe and fast way.
- Lack of attention to problems indicated in application, server and database logs. Usually they can contain important information that you should review periodically.
Using the auditor hat implies that you don't forget that you used the developer hat, before in other projects. This means that you understand some basic rules, that I always like to remind:
- Projects have history and constraints. Changes are usually introduced by who can't control them.
- Long term solutions make everyone happier than short term patchwork.
- In Drupal there is never a single right way of solving problems.
- The best tool for you is the one you know how to use.
I hope the list of topics I shared in the last two blog posts helped you and your project. I would also to link you to a tool developed by our network team that can help you immediatly tracing problems in your site: Acquia Insight. As part of Acquia Network you can try it for free for 30 days, when you install the Acquia connector module in your site. It will give a set of great recommendations regarding security, performance and best practices applied to your site.