Un permiso mal ajustado, una regla de bloqueo incompatible o una copia de wp-config.php olvidada puede exponer las claves de tu WordPress o dejar la web inaccesible. El riesgo no está solo en el archivo principal: backups, repositorios Git, procesos de despliegue y la configuración de Apache o Nginx pueden revelar secretos o provocar un error crítico en producción.
Control y protección de wp-config.php consiste en auditar quién puede leerlo y ejecutarlo, verificar que no sea accesible por HTTP, aplicar permisos y ownership compatibles con tu hosting y proteger secretos en copias y CI/CD.
Índice
Anuncio
Audita wp-config.php antes de cambiar nada
Control y protección de wp-config.php exige comprobar quién lee el archivo, bloquear su acceso web y mantener sus secretos fuera de lugares públicos.
Localiza la instalación y el webroot
Busca la carpeta que contiene wp-admin, wp-content y wp-includes; suele llamarse public_html, httpdocs, www o /var/www/html. Localiza wp-config.php en esa carpeta o un nivel por encima, y confirma cuál es el webroot: todo lo que quede dentro puede quedar expuesto si una regla falla.
Comprueba si hay exposición pública
Abre una ventana privada y visita https://tudominio.es/wp-config.php: el resultado correcto es 403 o 404, pero nunca 200, descarga ni texto PHP. Repite la prueba con wp-config.php.bak, wp-config.php.old, wp-config.txt, backup.zip y database.sql, porque una copia olvidada puede revelar las mismas credenciales que el archivo principal.
Registra permisos y vías de vuelta
Anota la ruta de wp-config.php, sus permisos, propietario y grupo; en SSH, ls -l wp-config.php muestra esos datos. Haz una copia fuera del webroot y comprueba que puedes descargarla. Además, define si revertirás por panel, SFTP, SSH o consola del proveedor antes de intervenir.
/wp-config.php, mientras la portada, /wp-admin y una consulta de la base de datos siguen funcionando.Con el inventario hecho, ya puedes ajustar el acceso local sin adivinar qué proceso necesita leer el archivo.
Ajusta permisos según propietario y PHP
Comprueba el propietario y el usuario de PHP antes de aplicar CHMOD.
Identifica quién ejecuta PHP
En hosting compartido, PHP suele ejecutarse con tu mismo usuario y 600 suele funcionar. En un VPS con PHP-FPM, puede funcionar bajo www-data, nginx o un usuario de pool distinto; consulta el panel, la configuración del pool o al proveedor y no uses chown a ciegas.
Elige el modo más restrictivo que funcione
CHMOD 600 es adecuado cuando el propietario del archivo es el mismo usuario que ejecuta PHP. Si PHP necesita entrar mediante el grupo, 640 puede ser válido si el grupo está correctamente asignado.
| Entorno | Permiso orientativo | Condición necesaria | Prueba tras el cambio |
|---|---|---|---|
| Hosting con PHP bajo tu usuario | 600 | Propietario y PHP coinciden | Portada y acceso a administración |
| PHP-FPM con grupo autorizado | 640 | PHP pertenece al grupo lector | Consulta a base de datos sin errores |
| Archivo solo legible por propietario | 400 | No necesitas editarlo desde WordPress | Actualización y restauración controladas |
| Grupo lector sin escritura | 440 | Propietario y grupo correctos | Logs de PHP-FPM sin denegaciones |
Aplica el cambio desde el gestor de archivos o con chmod 600 wp-config.php o chmod 640 wp-config.php, y prueba una página pública, el acceso y una acción que guarde datos.
Reconoce un permiso que falla
Un “Error establishing a database connection” tras el cambio suele indicar que PHP ya no puede leer las credenciales; también pueden aparecer errores 500, 502 o 503. Restaura el último modo funcional, revisa propietario, grupo y usuario PHP, y consulta el log de errores antes de aplicar otra restricción.
El acceso local ya está limitado; ahora toca cerrar la puerta pública.
Bloquea el acceso web según tu servidor
Deniega la petición directa a wp-config.php en el servidor que atiende tu dominio.
Añade la regla en Apache o LiteSpeed
Si usas Apache o LiteSpeed y permite .htaccess, abre el archivo situado junto a wp-config.php y añade estas líneas al principio, sin modificar las reglas estándar de WordPress:
<Files .php>
Require all denied
</Files>Configura el bloqueo en Nginx
Si usas Nginx y controlas su configuración, añade dentro del bloque server { } una regla exacta en el archivo activo del dominio:
location = /wp-config.php {
deny all;
access_log off;
log_not_found off;
}Después valida con nginx -t y recarga solo si la sintaxis es correcta; en hosting gestionado, pide al proveedor que aplique la regla.
Comprueba la respuesta y los logs
Visita https://tudominio.es/wp-config.php en una ventana privada o ejecuta curl -I. Debes obtener 403 o 404; un 200 obliga a detenerse, y los logs de acceso y errores confirman qué servidor atendió la petición y si rechazó alguna regla.
Bloquear la URL no protege los secretos que ya estén en copias o repositorios. Por eso, la decisión depende de qué capa controlas. En hosting compartido, prioriza permisos compatibles con el usuario de PHP, auditoría de copias públicas y reglas Apache o LiteSpeed cuando el proveedor admita .htaccess; si no tienes acceso a la configuración, solicita el bloqueo al soporte. En un VPS con Nginx y PHP-FPM, valida el usuario y el grupo de PHP antes de elegir CHMOD 600 o CHMOD 640, y aplica la regla en el bloque server. En Docker o CI/CD, evita cambios manuales persistentes dentro del contenedor: entrega secretos mediante variables de entorno o un gestor de secretos, conserva wp-config.php fuera de repositorios Git y define permisos, propietario de archivos y reversión en la imagen o en la automatización de despliegue.
En WordPress multisite, verifica además la ruta compartida y prueba el acceso de un subsitio antes de cerrar el cambio.
Separa secretos de Git y del despliegue
Saca las credenciales y los salts del repositorio de código.
Evita que Git guarde credenciales
Añade wp-config.php y .env a .gitignore y versiona una plantilla sin valores reales. Si el archivo ya estuvo en Git, borrarlo no elimina el secreto del historial: rota la contraseña de base de datos y revisa quién tuvo acceso al repositorio.
wp-config.php
.env
*.sql
*.zip
*.tar.gzInyecta variables por entorno
Las variables de entorno permiten usar credenciales distintas en producción, pruebas y desarrollo sin incluir contraseñas en el código. PHP puede leerlas con getenv(), por ejemplo define('DB_PASSWORD', getenv('DB_PASSWORD'));, pero prueba el patrón en preproducción porque algunos hostings no las pasan igual a PHP.
Rota sesiones y claves con aviso
Renovar las ocho claves y salts invalida las cookies y cierra todas las sesiones activas. Rótalos ante una filtración, una intrusión o al retirar accesos privilegiados, coordina el cambio en una ventana de bajo tráfico y rota también la contraseña de base de datos cuando corresponda.
La ubicación del archivo puede añadir protección, pero solo si encaja con tu arquitectura.
Además de los permisos de archivos y el bloqueo HTTP, conviene revisar las constantes de endurecimiento en wp-config.php según su impacto real. DISALLOW_FILE_EDIT desactiva el editor de temas y plugins del escritorio, una medida útil en producción para reducir cambios de código desde cuentas comprometidas. FORCE_SSL_ADMIN obliga a usar HTTPS en wp-admin cuando el certificado y la terminación TLS están correctamente configurados. WP_ENVIRONMENT_TYPE ayuda a diferenciar producción, desarrollo y pruebas.
En cambio, DISALLOW_FILE_MODS bloquea instalaciones, actualizaciones y cambios de plugins y temas desde el panel; puede ser apropiada en despliegues Git o CI/CD controlados, pero no en un sitio cuyo mantenimiento dependa del actualizador de WordPress.
Mueve el archivo solo si tu arquitectura lo admite
Mueve wp-config.php fuera del directorio público solo cuando controles las rutas y la reversión.
Valora si el traslado aporta seguridad
En una instalación convencional puedes mover el archivo un nivel por encima del directorio público, por ejemplo de /var/www/html a /var/www/wp-config.php. Haz una copia verificable, mueve solo el archivo y prueba portada, acceso y funciones con base de datos antes de considerar el cambio terminado.
Evita el traslado en casos delicados
No lo muevas manualmente en Docker, multisite, Bedrock, Composer, rutas personalizadas o despliegues que esperan una ubicación concreta. Si no puedes explicar dónde busca WordPress el archivo y cómo revertirás desde consola o SFTP, mantén su ubicación y refuerza permisos y bloqueo HTTP.
La última defensa es validar que la seguridad no haya interrumpido el servicio.
Anuncio
Valida el cambio y prepara la reversión
Prueba el bloqueo, la conexión y los logs antes de cerrar la intervención.
Haz pruebas sin revelar datos
Confirma 403 o 404 para /wp-config.php, abre portada y páginas internas, accede a /wp-admin, prueba un formulario y guarda datos. Mantén WP_DEBUG_DISPLAY desactivado en público; si investigas, registra errores mediante WP_DEBUG_LOG en un entorno controlado.
Lee los registros adecuados
Consulta el access log para confirmar ruta y código de respuesta, y el error log de Apache, Nginx o PHP-FPM ante errores 500, problemas de permisos o fallos de carga. Trata los logs con cuidado porque pueden contener IP y rutas internas.
Recupera rápido ante un error
Si falla la web, restaura primero el permiso, regla o ubicación anterior según tus notas y realiza un único cambio de reversión. Si no recuperas el servicio en 5 a 10 minutos, restaura la copia verificada de wp-config.php y solicita al proveedor los logs del momento exacto.
Con las pruebas documentadas, puedes resolver las dudas habituales antes de aprobar el cambio.
Preguntas frecuentes
¿Qué permisos debe tener wp-config.php?
600 suele funcionar cuando PHP se ejecuta con el mismo propietario del archivo. 640 puede ser necesario si PHP-FPM lee mediante un grupo autorizado; prueba siempre portada y administración tras cambiarlo.
¿Cómo sé si wp-config.php es accesible desde Internet?
Solicita https://tudominio.es/wp-config.php y confirma una respuesta 403 o 404. Un 200, una descarga o cualquier contenido visible exige revisar de inmediato el servidor y posibles copias públicas.
¿Puedo proteger wp-config.php con .htaccess?
Puedes bloquearlo con .htaccess si tu servidor usa Apache o LiteSpeed y admite esas reglas. Nginx ignora .htaccess, así que necesita una regla en su propia configuración.
¿Qué pasa si cambio los salts de WordPress?
Cambiar los ocho salts cierra todas las sesiones activas de WordPress. Hazlo tras una posible filtración y avisa antes a administradores, editores y usuarios con área privada.
¿Es seguro mover wp-config.php fuera del directorio público?
Es seguro en una instalación convencional si controlas rutas y puedes revertir el cambio. No es recomendable hacerlo manualmente en Docker, multisite o hosting gestionado sin confirmación del proveedor.
Mantén un control verificable
El archivo de configuración merece el mismo cuidado que las llaves de una oficina: limitarlo exige verificar servidor, usuario PHP y reversión.
- Audita ruta, copias públicas, permisos, propietario y acceso HTTP antes de editar.
- Elige entre
600y640según el usuario real que ejecuta PHP. - Comprueba siempre un 403 o 404 y revisa logs tras bloquear la URL.
- Mantén credenciales y salts fuera de Git, archivos públicos y copias sin cifrar.
- Conserva una reversión probada para recuperar el servicio sin afectar al negocio.
Anuncio
Para saber más
Si deseas profundizar, aquí tienes algunos recursos de interés:
- Protege el archivo wp-config.php de WordPress — webempresa.com
- Proteger wp-config.php en WordPress — inspectwp.com
- Cómo proteger wp-config.php en WordPress — seguridadenwordpress.com
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.