Proteger wp-config.php en WordPress

El archivo wp-config.php en el directorio raíz de toda instalación de WordPress contiene las credenciales de la base de datos (host, nombre, usuario, contraseña), las claves de seguridad y los salts secretos, así como constantes de configuración centrales. Si este archivo cae en malas manos, prácticamente todo el sitio queda comprometido. Por eso es el archivo individual más importante que hay que proteger. Esta guía muestra cuatro medidas de refuerzo: generar claves de seguridad nuevas, establecer permisos de archivo restrictivos, bloquear el acceso HTTP directo al archivo y añadir constantes protectoras como DISALLOW_FILE_EDIT. Opcionalmente, el archivo puede moverse un nivel por encima del webroot. Todos los pasos pueden realizarse en unos 20 minutos mediante SFTP/SSH y la configuración de .htaccess o nginx.

Paso 1: Regenerar las claves de seguridad y los salts

WordPress usa ocho cadenas secretas (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY y los cuatro valores _SALT correspondientes) para cifrar las cookies de inicio de sesión y los nonces. Si estos valores fueron públicos alguna vez (por ejemplo en una copia de seguridad accesible en la web) o nunca se cambiaron, deberías regenerarlos. WordPress ofrece un generador oficial para ello:

# Fetch current random values:
https://api.wordpress.org/secret-key/1.1/salt/

En wp-config.php, sustituye el bloque existente por los valores recién generados:

define( 'AUTH_KEY',         'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY',  'hier-langer-zufallswert' );
define( 'LOGGED_IN_KEY',    'hier-langer-zufallswert' );
define( 'NONCE_KEY',        'hier-langer-zufallswert' );
define( 'AUTH_SALT',        'hier-langer-zufallswert' );
define( 'SECURE_AUTH_SALT', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_SALT',   'hier-langer-zufallswert' );
define( 'NONCE_SALT',       'hier-langer-zufallswert' );

Tras guardar, todos los usuarios conectados se desconectan; es intencionado y una forma eficaz de invalidar sesiones robadas.

Paso 2: Establecer los permisos de archivo

wp-config.php debe ser legible para el servidor web, pero inaccesible para otros usuarios. Se recomienda 600 (solo el propietario puede leer/escribir) o 640 si el grupo del servidor web necesita acceso de lectura:

# Only owner reads and writes
chmod 600 wp-config.php

# Alternatively, if the web server group must read
chmod 640 wp-config.php

Nunca uses 777 o 666: con ello cualquier usuario del sistema puede leer el archivo y extraer las credenciales de la base de datos.

Paso 3: Bloquear el acceso HTTP directo

Normalmente wp-config.php se ejecuta como PHP y no devuelve salida. Sin embargo, si el procesamiento de PHP falla (mala configuración, migración de servidor), podría entregarse el contenido en texto plano. Bloquea el acceso directo además a nivel del servidor web.

Apache (.htaccess)

<Files wp-config.php>
    Require all denied
</Files>

nginx

location = /wp-config.php {
    deny all;
    return 403;
}

Paso 4: Añadir constantes de refuerzo

En wp-config.php, encima de la línea /* That's all, stop editing! */, añade las siguientes constantes:

// Disable the file editor in the admin area (prevents editing
// theme and plugin code via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Optional: completely prevent installing/updating plugins and
// themes via the dashboard (strictest variant)
// define( 'DISALLOW_FILE_MODS', true );

// Disable debug output in production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Enforce encrypted connections in the admin area only
define( 'FORCE_SSL_ADMIN', true );

// Limit automatic core updates to security releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT es especialmente importante: sin esta constante, un atacante que tome el control de una cuenta de administrador puede ejecutar código PHP arbitrario directamente desde Apariencia » Editor de temas.

Opcional: Mover wp-config.php fuera del webroot

WordPress también busca wp-config.php un nivel de directorio por encima del webroot. Si tu WordPress está en /var/www/html/, puedes mover el archivo a /var/www/wp-config.php. Así queda fuera del área accesible por HTTP.

Atención: Esto solo funciona de forma fiable en instalaciones clásicas de un solo sitio con webroot propio. En hosting compartido, donde varios sitios comparten el mismo nivel superior, moverlo puede causar conflictos. En caso de duda, consulta con tu proveedor.

¿Cómo compruebo que la protección funciona?

1. Abre https://tu-dominio.com/wp-config.php en el navegador. Esperado: una página vacía (ejecución de PHP) o 403 Forbidden (acceso bloqueado); nunca código fuente PHP legible.
2. Por terminal:

   curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/wp-config.php
   # Expected: 403 (with an active block) or 200 with an empty body

3. Comprobar los permisos:

   ls -l wp-config.php
   # Expected: -rw------- (600) or -rw-r----- (640)

4. En el área de administración, confirma que ya no aparece ningún editor en Apariencia ni en Plugins (efecto de DISALLOW_FILE_EDIT).

Errores frecuentes

• Permisos demasiado estrictos: En algunos proveedores PHP no se ejecuta como propietario del archivo. Entonces 600 puede provocar un error 500; en ese caso usa 640 o 644.
• Claves sustituidas sin copia de seguridad: Haz una copia del archivo antes de los cambios. Un error tipográfico en las constantes deja el sitio inaccesible.
• DISALLOW_FILE_MODS demasiado pronto: Esta constante también bloquea las actualizaciones normales de plugins/temas desde el panel. Actívala solo si las actualizaciones se hacen exclusivamente por despliegue/WP-CLI.
• Archivo movido, pero ruta incorrecta: Al moverlo fuera del webroot, no montes un cargador require propio que revele una ruta absoluta del servidor.

Preguntas frecuentes (FAQ)

¿Qué permiso de archivo debería tener wp-config.php?

Se recomienda 600 (solo el propietario puede leer y escribir). Si en tu hosting PHP no se ejecuta como propietario del archivo sino a través del grupo, usa 640. Nunca uses 777 o 666, porque entonces cualquier usuario del servidor puede leer las credenciales de la base de datos.

¿Qué ocurre si cambio las claves de seguridad en wp-config.php?

Todos los usuarios conectados se desconectan y deben volver a iniciar sesión. Es intencionado y una forma eficaz de invalidar cookies de sesión robadas. El contenido del sitio no cambia. Genera valores nuevos con el generador oficial de claves secretas de WordPress.

¿Para qué sirve la constante DISALLOW_FILE_EDIT?

DISALLOW_FILE_EDIT desactiva el editor de temas y plugins en el área de administración de WordPress. Sin esta constante, un atacante que tome el control de una cuenta de administrador puede ejecutar código PHP arbitrario directamente desde Apariencia » Editor de temas. Por eso es una de las medidas de refuerzo más importantes.

¿Debería mover wp-config.php fuera del webroot?

WordPress también busca wp-config.php un nivel de directorio por encima del webroot. En instalaciones clásicas de un solo sitio con webroot propio, moverlo aumenta la seguridad. En hosting compartido, donde varios sitios comparten el mismo nivel superior, puede causar conflictos; en caso de duda, consulta con tu proveedor.

¿Cómo ayuda InspectWP con wp-config.php?

Durante el rastreo, InspectWP comprueba, entre otras cosas, si archivos sensibles como wp-config.php o una copia wp-config.php.bak están accesibles públicamente, si el área de administración se fuerza por HTTPS y si la salida de depuración se filtra al exterior. Los hallazgos correspondientes se marcan como riesgo de seguridad en el informe.