Is there any security risk to use getenv() inside settings.php to populate databases variable from a .env file?

Question

I am using the Drupal composer project, which doesn't use getenv() by default. I wanted to use the following code inside the settings.php file in a production site.

  $databases['default']['default'] = array (
   'database' => getenv('MYSQL_DATABASE'),
   'username' => getenv('MYSQL_USER'),
   'password' => getenv('MYSQL_PASSWORD'),
   'prefix' => '',
   'host' => getenv('MYSQL_HOSTNAME'),
   'port' => getenv('MYSQL_PORT'),
   'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
   'driver' => 'mysql',
);

I read somewhere we shouldn't use getenv() in production sites. What are the downsides of it? Is there any security issue?

Answer 1

If the .env file is outside the server document root, using getenv() is similar to putting the hash salt in a file and reading it with file_get_contents() as the following comments in the default.settings.php file suggest to do. (The same comment is present in the default.settings.php file for Drupal 7, so it's not a matter of which Drupal version is used.)

/**
 * Salt for one-time login links, cancel links, form tokens, etc.
 *
 * This variable will be set to a random value by the installer. All one-time
 * login links will be invalidated if the value is changed. Note that if your
 * site is deployed on a cluster of web servers, you must ensure that this
 * variable has the same value on each server.
 *
 * For enhanced security, you may set this variable to the contents of a file
 * outside your document root; you should also ensure that this file is not
 * stored with backups of your database.
 *
 * Example:
 * @code
 *   $settings['hash_salt'] = file_get_contents('/home/example/salt.txt');
 * @endcode
 */
$settings['hash_salt'] = '';

If that is considered enhanced security, the same can be said for reading some values using getenv(), if the file containing the values of the environment variables is not in the server document root.

Keep in mind that, if somebody would be able to write a PHP file on the server, it would also be possible for them to read the environment variables and the file containing the hash salt.

Answer 2

You may be telling about this Production environments rarely use .env files.. Someday I also went through this line. Though still I don't know what is this why it has been written like this ?

<?php
/**
 * This file is included very early. See autoload.files in composer.json and
 * https://getcomposer.org/doc/04-schema.md#files
 */
use Dotenv\Dotenv;
use Dotenv\Exception\InvalidPathException;
/**
 * Load any .env file. See /.env.example.
 */
$dotenv = new Dotenv(__DIR__);
try {
  $dotenv->load();
}
catch (InvalidPathException $e) {
  // Do nothing. Production environments rarely use .env files.
}

https://github.com/drupal-composer/drupal-project/blob/8.x/load.environment.php