Your website needs to grow, securely. Therefore, even if it’s built on the born-secured Drupal stack, you have to keep one eye on its performance and the other on its stability. It implies you have to run a regular check on the three aspects - security, performance, and stability - to ensure your site is maintained properly. In brief you have to run a site audit regularly, without waiting for the signs of delay.
Signs of Delay
If your regular site monitoring reveals that your site visit is declining, peak hour traffic leads to crash and threats lay attended then it’s for sure that an audit is past due.
To hold you back from falling in the site-audit-delay trap and help you identify what needs to be done, here’s a detailed checklist for a robust audit plan.
Although Drupal websites are meant to be secured by birth, don’t take that for granted. Security is not a product, it’s a process you need to follow. The Drupal security team believes that adage, hence every now and then they release new security updates. Don’t forget to patch your site with those. That way you’ll take care of the extensively reviewed and professionally audited Drupal core codebase. When it comes to the contributed projects i.e. the different Drupal APIs, you need to be a little more careful. They go through comparatively lesser cycles of peer reviews. You ought to be cautious while configuring them to your site. Any casual slip-up will invite major security threats. With that difference in approach, check for the following when you get on with a security audit:
1.1 Updated Drupal
This should be at the top of the agenda. An updated Drupal always carries the best in class security features. To know when to update, keep a close focus on either mail from Drupal or on the Drupal Security Advisories. The latter contains a chronological record of the security risks, their level of criticality, and the solutions to mitigate that risk that comes with suggestions and a link to upgrade. In case your team is too busy swatting other tech issues, you keep an eye for emails from Drupal Security Advisory. You’ll find the same information in the mails.
1.2 Integrity Check
For the purpose of your site, your Drupal developers may modify the core or contributed code. It may help in meeting certain objectives but also leads to complications in code maintenance and update. In the long run, such modifications leave the site vulnerable. Often these vulnerabilities arise from the erroneous configuration with the injection of XSS, CSRF, and SQL in the custom code. Therefore, at the time of audit, you have to keep an eye on the code modifications to look out for areas that are left open to threat.
1.3 File Permission
No way you can allow anyone to have “write” access on to the web server and thereby the codebase. They should be in pristine condition. While checking for weak spots, find out if your web server has only “read” access for all files. Ideally, no private files should be placed on this server. In case of dire requirements, allow the files outside the webroot.
1.4 Review Roles
Drupal lets you assign different types of roles, and their corresponding tasks using a fine-grained permissions model for different users. This helps at three different levels.
• Execution level: Where a user is accountable for the assigned tasks
• Managerial level: Where role reviewing for managers becomes super easy
• Organization level: Where the site can be kept secured in the hands of the selected few with critical site altering permission
1.5 Configure Input
The input filter of a Drupal site needs careful adjustments. Enable the PHP filter, and you’ll allow putting PHP code in the database. It’s an invitation to hack your site, as the attackers can easily find out that your site can be used to execute PHP codes. Even if you don’t get hacked, it’ll make debugging difficult. To keep your database secured, check if the PHP filter is disabled.
Enable Full HTML and you’ll leave the comments section unguarded. Any user with malicious intent may use that as a possible backdoor to seed a threat. For the sake of security, keep HTML filtered and block users from planting a threat in the comment section.
1.6 Use HTTPS
Your customer will trust you only when they see you care for their data. Show that by encrypting your site with HTTPS. Encrypt all HTTP requests on your site so that no one can eavesdrop on your data or gets the opportunity to tamper with your users’ privacy. Additionally, it nudges your SER rank.
1.7 Block Cross-Site Function
Drupal offers at least eight APIs to filter out and prevent Cross-site scripting or XSS attack and blocks most of the script injection attempts. In parallel, Drupal deploys functionalities like HTTP POST to validate user intention and counter Cross-site Request Forgery (CSRF) that can delete database objects. To prevent CSRF in POST request, the Form API implements unique form tokens.
1.8 Anti-Spam Measures
Hackers and spammers have become smarter. Their attacks are not limited to database tables, they use bots to fill forms and submit comments on your site. Find out whether captcha/recaptcha are implemented in the forms. They are a great tool to keep any bot attacks or script attacks at bay.
1.9 Tools to Consider
For quick review of your site security here is a suggestive list that we feel will help you get your job done:
1.9.1 Security Review
The Security Review module offers a comprehensive report on areas that are prone to malicious attacks.
1.9.2 Security Kit
To prevent XSS, CSRF, and clickjacking attacks you may use Security Kit.
Hacked checks for modifications done to the core and contrib code.
The module is meant to check that the texts are sanitized.
1.9.5 Site Audit
If yours is a static site, use Site Audit for a quick analysis report.
The first indicator of site performance is speed. If your site is loading in less than three seconds, you’re good. Bring it down to sub 1.5 seconds and you’re a winner. Both search engine giants and users will praise you. The result will show on SERP ranking, in site metrics and finally on the P&L. Here’re a set of areas where you need to focus while auditing site performance.
2.1 Server Configuration
At a functional level, the performance of your site is dependant on four resources: available bandwidth, CPU speed, freed memory, and usable I/O disk space. Configure these four separately as per the requirement of your site. To find the out the requirement, profile your site by:
• Analyzing traffic pattern
• Checking the number of page views
• Finding the impact of concurrent users
You can also try to find out if there are any bottlenecks in one of those four resources. Once identified, quickly decide between a change in configuration or resource upgrade.
2.2 Caching Strategies
Caching at different level makes your site perform that much better. It allows for saving time and offering better site experience. Particularly for a Drupal site, which is PHP driven, it’s even more important as PHP isn’t a compiled language and takes time to process a service request. If you have a deliberate caching strategy you can serve already compiled pages from the cache and save the page download time substantially. During an audit, some of the caching methods that you should look out for:
2.2.1 Browser Caching
Set an optimum time limit for a browser to store page information before checking with the server for an update or fresh download. You can even set browser cache to store site information that doesn’t change frequently and save a few additional seconds.
2.2.2 Content Delivery Network
With a CDN service you can serve your users’ request from a remote server located physically near to the user. It helps in the quick download of the page and thereby in pushing up the overall site performance.
2.2.3 Reverse Proxy
A reverse proxy service like Varnish, creates an interim layer between the web server and a user. Therefore, when your user sends for a page request, it gets served through reverse proxy server without bringing in the web server in the picture.
2.2.4 Opcode Cache
This is another option that’s super useful in taking off the PHP compilation overhead. The common ones like APC and Opcache precompile the PHP code and store them as bytecode that uses less time to process. As its effect, a user gets to see a page quicker.
2.2.5 Internal Cache
Drupal’s internal cache lets you store blocks, views, and even pages. Consider how much time, of your user, will it save, if it serves a page request straight from the cache. By default, the cache is stored in the database. For effective management, you may choose to use distributed cache like Memcache or Redis.
2.3 Back-end Review
.Keep the back-end lite for a fast site download by profiling the code and checking the database logs. In case you find database logging in production, disable it so that logs don’t write on the database and make it heavy. Use syslog instead. Find out if there are any defunct or outdated module. If there are any, disable or uninstall them to keep the back-end as lean and operational as possible to deliver better performance.
2.4 Front-end Review
• Web compatible format
• Uncompromising quality at optimum size
• Usage of image sprites
• CSS are aggregated and compressed
2.5 Performance Auditing Tool
For quick review of your site performance here is a suggestive list that we feel will help you get your job done:
2.5.1 New Relic
New Relic offers different products to keep an eye on different components ranging from app to infrastructure.
XHProf profiles codes by analyzing application at run-time and identifying bottlenecks and performance issues.
2.5.3 PageSpeed Insight, YSlow, GTMetrix
While looking into the stability of your site, you need to focus on the following:
• The architecture of the site
• The breadth and depth of the developer’s documentation
• The quality of the code
• The process in which the code has been written
Together, these factors construct a robust framework for your site. If they lack in the best practices, you may need to take prompt action. Any weakness in those aspects indicates a looming danger that may turn out to be critical real soon.
The most common tool to check code quality and find out where standard codes have been used is Coder Sniffer. Tools like Coder Sniffer also fixes coding standard errors.
In addition to the codes, while auditing for stability you may need to look into:
• Factors that contribute to the SEO
• Quality of links
• Freshness of modules and functionalities
• Breadth of documentation
• Access to documentation
• Cycles of peer review for codes
An audit cycle is the first step towards a daily maintenance chore. You may have maintenance sessions for your Drupal site scheduled regularly. But even before you get on with the maintenance, you need to know which aspect of your site needs care. A site audit lets you find that out. Besides acting as a precursor to site maintenance, a site audit helps in identifying both the strengths and weaknesses of your site. The way it assures the robustness of your online business, in the similar way it shows you where you are prone to get attacked.
Pity, if only Titanic had an audit before she sailed.