Configuración de variables de entorno seguras para aplicaciones PHP

En hosting compartido no siempre tienes control de nivel sistema, por eso proteger secretos (contraseñas, API keys, salts) requiere estrategias prácticas y ajustadas a las limitaciones del entorno. En este artículo explico métodos seguros para configurar variables de entorno en aplicaciones PHP, ejemplos prácticos (.env, .htaccess, cPanel), y las buenas prácticas operativas que debes aplicar para minimizar riesgos.

Por qué no debes hardcodear secretos en código

Incluir contraseñas y tokens directamente en el código fuente es la causa más habitual de fugas de información. Los riesgos en hosting compartido son mayores por:

  • Acceso limitado al sistema: no puedes usar gestores de secretos a nivel de servidor.
  • Posibles errores de configuración del servidor que expongan ficheros.
  • Copias de seguridad del proveedor que pueden contener datos sensibles.

Por tanto, la mejor práctica es separar configuración y código: el código debe leer las variables de entorno, y los secretos deben almacenarse fuera del repositorio y fuera del webroot cuando sea posible.

Opciones prácticas para almacenar variables de entorno en hosting compartido

1) Archivo .env fuera del webroot con vlucas/phpdotenv

Colocar un archivo .env en un directorio fuera de public_html (por ejemplo: /home/usuario/config/.env) y cargarlo con vlucas/phpdotenv es una solución sencilla y portable:

// composer require vlucas/phpdotenv
require __DIR__ . '/../vendor/autoload.php';
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__ . '/../config');
$dotenv->load();
$dbPass = $_ENV['DB_PASSWORD'] ?? getenv('DB_PASSWORD');

Ventajas: simple, portable y no requiere permisos root. Debes asegurarte de que el directorio donde guardas .env no esté accesible desde la web y tenga permisos restrictivos (600/640).

2) .htaccess y SetEnv (cuando Apache lo permite)

Algunos hosts permiten usar SetEnv en .htaccess para definir variables de entorno que PHP puede leer con getenv():

# .htaccess
SetEnv DB_PASSWORD "mi_secreto_compartido"

Limitaciones: si el proveedor permite descargas directas de ficheros .htaccess por mala configuración, existiría riesgo. Además, las variables definidas en .htaccess pueden ser visibles en ciertos entornos o logs, así que evalúa el riesgo.

3) Variables del panel (cPanel, Plesk u otro)

Algunos paneles de hosting ofrecen sección para «variables de entorno» o «Aplicación» donde puedes guardar claves. Ventajas: integradas, gestionables desde UI. Contras: no siempre están disponibles y varían por proveedor. Consulta la documentación del hosting y privilegios de usuario.

4) Archivos de configuración PHP fuera del webroot

Usar un archivo PHP que retorne un array con la configuración, ubicado fuera de public_html, es una técnica robusta:

// /home/usuario/config/config.php
return [
  'db' => [
    'host' => 'localhost',
    'user' => 'usuario',
    'pass' => 'mi_password'
  ]
];

// index.php
$config = require __DIR__ . '/../config/config.php';

Si el fichero está fuera de la raíz web y con permisos 600, resulta seguro y no depende de extensiones externas.

5) auto_prepend_file o .user.ini para inicializar variables

En hosts que permiten .user.ini o auto_prepend_file, puedes incluir un pequeño bootstrap que establezca constantes o lea un archivo seguro antes de ejecutar la aplicación. Ejemplo en .user.ini:

auto_prepend_file = "/home/usuario/config/env_bootstrap.php"

En env_bootstrap.php defines constantes con putenv() o define(). Útil cuando no puedes modificar el código principal.

Lectura segura de variables en PHP

Independientemente del método elegido, usa las APIs recomendadas:

  • getenv('KEY')
  • $_ENV['KEY'] si está disponible
  • defined('CONST') ? CONST : getenv('KEY') para compatibilidad
// Ejemplo defensivo
$dbPass = getenv('DB_PASSWORD') ?: ($_ENV['DB_PASSWORD'] ?? null);
if (empty($dbPass)) {
  throw new RuntimeException('DB_PASSWORD no está definido');
}

Buenas prácticas de seguridad y operativas

  • Permisos: ficheros de configuración fuera del webroot con chmod 600 y propietario correcto.
  • No subir .env al control de versiones. Usa .gitignore y revisa commits históricos.
  • Rotación de secretos periódica (cada 90 días o según la criticidad).
  • Principio de menor privilegio: la cuenta DB debe tener solo permisos necesarios.
  • No mostrar errores en producción: display_errors = Off y logs controlados.
  • Evitar pasar secretos por query string o headers sin cifrado; siempre HTTPS.
  • Evitar almacenar secretos en la base de datos sin cifrado; si los almacenas, encripta con una clave fuera de la base de datos.
  • Controla el acceso SSH/FTP y utiliza contraseñas robustas y 2FA si el host lo permite.

Consideraciones específicas para WordPress en hosting compartido

WordPress en hosting compartido es muy común y requiere precauciones sencillas:

  • Coloca wp-config.php en el directorio raíz pero carga valores sensibles desde un archivo fuera del webroot o desde variables de entorno.
  • Ejemplo en wp-config.php:
// wp-config.php
define('DB_NAME', getenv('DB_NAME'));
define('DB_USER', getenv('DB_USER'));
define('DB_PASSWORD', getenv('DB_PASSWORD'));
// Salts
define('AUTH_KEY', getenv('AUTH_KEY'));

Si no puedes usar variables de entorno, al menos mueve wp-config.php una carpeta arriba o utiliza constantes definidas en un archivo de configuración protegido.

Checklist de implementación rápida

  • ¿Los secretos están fuera del repositorio? (Sí/No)
  • ¿Los ficheros sensibles están fuera de public_html y con permisos 600?
  • ¿Se usan getenv o $_ENV en lugar de valores hardcodeados?
  • ¿Se ha desactivado display_errors en producción?
  • ¿Existe un plan de rotación y revocación de claves?
  • ¿Se minimizan permisos en las cuentas (DB, FTP, panel)?

Escenarios y recomendaciones según restricciones del host

  • Si puedes usar composer y ejecutar vendor: usa phpdotenv y .env fuera del webroot.
  • Si no puedes instalar paquetes, usa un archivo PHP de configuración fuera de public_html.
  • Si el host ofrece variables en el panel (cPanel/Plesk): es la opción más limpia; documenta su uso.
  • Si sólo dispones de .htaccess: usa SetEnv con cautela y revisa la política de backups del proveedor.

Conclusión

En hosting compartido, la seguridad de las variables de entorno depende de separar la configuración del código, restringir el acceso a los ficheros y elegir el método que mejor se adapte a las restricciones del proveedor. Las soluciones más prácticas son: colocar archivos de configuración fuera del webroot, usar phpdotenv si puedes, aprovechar las variables del panel cuando estén disponibles y, en última instancia, usar .htaccess con precaución. Acompaña siempre estas medidas con permisos estrictos, rotación de claves y control de acceso. Con estas prácticas reducirás significativamente el riesgo de exposición de secretos en entornos compartidos.

Tags: