Information Disclosure, also known as information leakage, is when a website unintentionally reveals sensitive information to its users. Depending on the context, websites may leak all kinds of information to a potential attacker, including:

1. Data about other users, such as usernames or financial information
2. Sensitive commercial or business data
3. Technical details about the website and its infrastructure

Although Drupal when correctly deployed is very secure, I’ll talk about the third item in the list, and how Drupal can and should be fortified for additional security.

In Drupal, Linux style file permissions are a critical part of the build, as per Drupal’s excellent documentation. In practice, though, I have seldom seen perfect compliance. Usually, permissions are set too weak.

This is not really the fault of Drupal per se, in my experience, problems with server file and folder permissions on Linux with PHP applications are pretty common, specially in an enterprise which uses both Windows and Linux servers in a distributed architecture.

If you navigate to https://yourdrupalsites.name/core/COPYRIGHT.txt, in a web browser, and the file’s contents are displayed for you to read, you should probably adjust the file permissions of your site’s core directory to be more restrictive if possible.

sudo chmod 664 -R core

All the files of a Drupal installation should be owned by the user account associated with the web server, for instance, in the case of the Apache2 service the username is “www-data”, thus the command would be:

sudo chown www-data -R core

Without going deeply into why Drupal websites chronically suffer from this misconfiguration, Drupal devs working in the US Public Sector can often find themselves in the position where we can’t easily follow the Drupal recommended best practice with file permissions.

Not to worry! Drupal is still more than capable of being secure, even if the doc root file permissions are FUBAR.

To begin, we can look at text files. All the files listed here give out large chunks of information about how our Drupal site is constructed. In Drupal’s /core directory, there are a few files that can be removed to reduce the information hackers can get by parsing the site files. We can safely delete the following files from our production Drupal codebase:

/core/CHANGELOG.txt
/core/COPYRIGHT.txt
/core/.deprecation-ignore.txt
/core/INSTALL.mysql.txt
/core/INSTALL.pgsql.txt
/core/install.php
/core/INSTALL.sqlite.txt
/core/INSTALL.txt
/core/LICENSE.txt
/core/MAINTAINERS.txt
/core/UPDATE.txt
/core/USAGE.txt

Removing install.php seems radical at first, (that file is “install screen” of a web install), but then when you think about how someone who can read your directory contents can access that page and re-install your whole website, it makes sense. Since you are already using Composer to manage your Drupal website’s software dependencies, you don’t really need it, just make sure you take these files out of the GIT flow, because every time you run Composer updates in a Drupal site these files are automatically replaced or regenerated. Perfect for a classy software application – terrible for a weak or compromised web server environment. In Drupal, the /libraries directory (if your installation has one), is also a great place to find information disclosing text files.

One way many sites telegraph information about themselves, Drupal included, is through a META tag Drupal generates called the “Generator” META tag. Here is what it looks like when you view the source of any Drupal content.

This tells the world that this is a Drupal site. In a perfect world this would be a point of monumental pride because we are using the most performant CMS ever invented, but for hardened Drupal installations, we need to not give the enemy any advantages they might use to craft attacks against Drupal’s structure.

Hold on, don’t panic! This is Drupal, and we have a module for that.

The Remove Generator META tag module easily fixes this information leakage, and I recommend using it on any Drupal site used in the Public Sector, where security must be ironclad. No configuration is needed once the module is onboarded and enabled.

These are just a few ways we can limit the information that bad actors can obtain through scanning our Drupal sites. Although Drupal does an excellent job of creating a secure software product, every Drupal site can differ depending on its environment and how it was designed to function.
Good luck, Drupalers, and deploy securely whenever possible!

Recommendations for Federal Vulnerability Disclosure Guidelines