wp-config.php es el archivo más crítico de cualquier instalación de WordPress porque contiene las credenciales de tu base de datos (usuario y contraseña MySQL), las salts de encriptación para cookies, y configuraciones sensibles del sitio. Si un atacante accede a este archivo, tiene control total de tu WordPress. Las técnicas más efectivas para protegerlo son tres: mover el archivo un nivel arriba del document root (donde WordPress lo busca automáticamente pero está fuera del alcance web), aplicar reglas .htaccess que bloqueen acceso directo, y configurar permisos CHMOD restrictivos (600 o 400) para que solo el propietario pueda leerlo.
En 30 segundos
- Mové wp-config.php un nivel arriba del document root: WordPress lo busca automáticamente allí, pero está fuera del alcance web incluso si PHP falla.
- Usá .htaccess para bloquear acceso directo al archivo:
<Files wp-config.php> deny from all </Files> - Configurá permisos CHMOD en 600 o 400: solo el propietario puede leer, grupo y públicos están bloqueados.
- Desactivá WP_DEBUG en producción y protegé el archivo debug.log con permisos restrictivos y nombre impredecible.
- Monitoreá cambios en tiempo real con plugins como Jetpack o WP Activity Log para detectar intentos de manipulación.
Qué es wp-config.php y por qué es el archivo más crítico de WordPress
wp-config.php es el archivo de configuración principal de WordPress. Contiene tres tipos de información sensible: credenciales de base de datos (DB_NAME, DB_USER, DB_PASSWORD), salts y keys de encriptación para sesiones y cookies, y constantes que definen el comportamiento del sitio (WP_DEBUG, WP_MEMORY_LIMIT, etc.). Si alguien accede a este archivo, tiene el nombre de usuario y contraseña de tu MySQL, lo que le permite modificar posts, robar datos, o destruir la base de datos.
El riesgo es mayor en hosting compartido, donde otros sitios comparten el mismo servidor. Si PHP falla globalmente y el servidor devuelve archivos como texto plano, wp-config.php se expone sin que ni siquiera lo notes. (Spoiler: ya pasó varias veces.) Por eso la protección no es opcional: es el equivalente a dejar la puerta de tu casa sin cerradura mientras viajas.
La técnica más segura: mover wp-config.php fuera del document root
WordPress incluye una característica pocas veces mencionada: busca wp-config.php en la carpeta raíz del sitio, y si no lo encuentra, sube un nivel automáticamente. Esto significa que podés mover el archivo fuera del document root web y WordPress seguirá funcionando.
Ponele que tu estructura es así: /home/usuario/public_html/wordpress/ (aquí está tu instalación) /home/usuario/private/ (esta carpeta NO es accesible por web) Movés wp-config.php a /home/usuario/private/ y WordPress lo encuentra sin problemas. La ventaja clave: incluso si el servidor se comporta mal y devuelve archivos como texto plano en vez de ejecutar PHP, wp-config.php nunca será accesible vía HTTP porque está fuera del directorio web.
Cómo hacerlo: conectate por SFTP o terminal, ubicá wp-config.php en /public_html/wordpress/, cortalo (no copies, cortalo), y pegalo un nivel arriba, en /public_html/. Luego probá que el sitio siga cargando. Si ves que WordPress funciona normal, listo, ya está protegido en una capa que casi nadie toca. Para más detalles técnicos, mirá proteger formularios de inyecciones SQL.
Protección mediante .htaccess: bloquear acceso directo
Si no podés mover el archivo (algunos hostings no lo permiten), la segunda línea de defensa es bloquear acceso directo con .htaccess. Agregá esto al archivo .htaccess en la raíz de tu WordPress:
<Files wp-config.php>
order allow,deny
deny from all
</Files>
Esto previene que alguien acceda a wp-config.php vía HTTP, pero WordPress sigue pudiendo leerlo internamente porque la regla solo afecta solicitudes web externas. La limitación: si el servidor ejecuta PHP de forma insegura o hay una vulnerabilidad en un plugin, .htaccess no detiene el acceso. Por eso es una capa complementaria, no una solución completa. Usá esto junto con permisos CHMOD restrictivos.
Configurar permisos CHMOD correctos: 600 vs 644
Los permisos de archivo en sistemas Unix/Linux se expresan en código CHMOD. Por defecto, wp-config.php suele estar en 644, lo que significa: propietario puede leer y escribir (6), grupo puede leer (4), público puede leer (4). Eso es un problema grave.
La protección correcta es CHMOD 600: solo el propietario del archivo puede leer y escribir. Grupo y públicos tienen cero acceso. Algunos administradores son aún más restrictivos con 400 (solo lectura para el propietario, que es suficiente porque WordPress no necesita escribir en wp-config.php después de instalación).
Cómo aplicarlo: si tenés acceso al hosting, entrá por SFTP o terminal y ejecutá:
chmod 600 wp-config.php
Luego verificá que el sitio siga funcionando. Si usás terminal, podés comprobar el permiso con ls -la wp-config.php y deberías ver algo como -rw------- 1 usuario usuario. Ojo: algunos hostings shared tienen restricciones raras y CHMOD 600 puede romper la ejecución si el usuario web no es el propietario del archivo. Si pasa eso, probá con 640 (propietario leer-escribir, grupo leer) como compromiso. Ya lo cubrimos antes en agregar capas de protección en tu servidor.
Desactivar WP_DEBUG en producción y proteger debug.log
Acá viene lo bueno: si tenés WP_DEBUG activado en producción, WordPress muestra errores de PHP directamente en la página. Esos errores pueden exponer rutas del sistema (/var/www/html/…), nombres de archivos, credenciales parciales, y versiones de librerías. Es como colgar un cartel que dice «mírenme, acá hay vulnerabilidades».
En wp-config.php, verificá estas líneas:
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
WP_DEBUG en false previene que se logueen errores. WP_DEBUG_DISPLAY en false garantiza que aunque WP_DEBUG esté true por algún motivo, los errores no aparezcan en la página web, solo en logs. Y WP_DEBUG_LOG redirecta los errores a wp-content/debug.log.
El tema es que debug.log es un nombre predecible y accesible por URL si está en wp-content. Solución: movelo a una carpeta fuera del document root, igual que wp-config.php. O mejor aún, cambiá el nombre a algo impredecible:
define('WP_DEBUG_LOG', '/home/usuario/private/logs-abc123-2026.log');
De esa forma, incluso si alguien intenta acceder a debug.log, no lo encuentra porque está fuera del web root y con nombre aleatorio. Tema relacionado: combinar con herramientas de defensa profesionales.
Monitoreo de cambios: detectar modificaciones no autorizadas
La protección no termina con bloqueos: necesitás saber si alguien intentó modificar wp-config.php. Los atacantes a veces inyectan código malicioso o cambian credenciales de base de datos para mantener acceso después de que limpiés el sitio.
Opciones de monitoreo:
1. **Plugins como Jetpack, WP Activity Log o Wordfence**: detectan cambios en archivos críticos en tiempo real y envían alertas por email. Jetpack Security cuesta USD 5/mes y monitorea modificaciones no autorizadas.
2. **Crear un backup y comparar hashes**: descargá wp-config.php, generá su hash SHA256 con sha256sum wp-config.php, guardalo en un lugar seguro, y ejecutá el comando cada semana. Si el hash cambia, alguien modificó el archivo.
3. **File Integrity Monitoring (FIM)**: si tenés acceso a terminal, usá herramientas como AIDE o Tripwire que monitorean cambios en tiempo real. Más técnico, pero extremadamente confiable.
Consideraciones especiales en hosting compartido
En hosting compartido, otros 50 sitios pueden estar en el mismo servidor. Si hay un bug global en PHP o Apache, wp-config.php podría exponerse a otros clientes del hosting. Las medidas básicas (mover arriba, CHMOD 600) son aún más críticas acá.
Recomendaciones específicas para shared hosting: – **Mover wp-config.php es obligatorio**: no es un «nice to have», es essential. – **Verificá que tu hosting permita acceso SFTP o SSH**: algunos hostings baratos solo ofrecen FTP (inseguro) y no dejan ejecutar comandos chmod. – **Usá hosting con aislamiento de usuarios**: donweb.com y otros hostings argentinos modernos corren PHP en modo FCGi por usuario, lo que significa que otros sitios no pueden leer archivos ajenos aunque estén en la misma máquina. – **Si te ofrecen VPS o dedicado**: la inversión vale la pena por seguridad. En VPS, sos el único usuario del servidor, así que wp-config.php está aislado de otros sitios de terceros.
Tabla comparativa: técnicas de protección
| Técnica | Costo de implementación | Efectividad | Complejidad | Recomendación |
|---|---|---|---|---|
| Mover wp-config.php arriba | Gratis (acceso SFTP) | Muy alta | Baja | Obligatoria en cualquier sitio |
| .htaccess + bloqueo | Gratis | Alta (capa complementaria) | Muy baja | Agregá siempre, junto con mover archivo |
| CHMOD 600 | Gratis (acceso SSH/SFTP) | Alta | Baja | Hazlo en paralelo con las otras técnicas |
| Desactivar WP_DEBUG | Gratis (editar wp-config.php) | Media (previene exposición de errores) | Muy baja | Obligatorio en producción |
| Monitoreo de cambios (Jetpack/WF) | USD 5-10/mes | Alta (detecta intentos) | Media (setup plugin) | Recomendado para sitios críticos |
| Cambiar nombre del archivo | Gratis (editar wp-config.php) | Muy baja (no compatible con WP moderno) | Alta (causa errores) | NO recomendado |
Errores comunes que comete la gente
1. Creer que .htaccess solo es suficiente
.htaccess es una capa importante, pero no es inmune a fallos. Si hay un bug en el servidor o una vulnerabilidad en un plugin que permite lectura de archivos, .htaccess no detiene nada. Usalo junto con las otras técnicas, no como solución única.
2. Dejar WP_DEBUG activado en producción
WP_DEBUG=true es genial para desarrollo local, pero en producción expone información de debug públicamente. Es lo primero que hacen los atacantes: acceden a ejemplo.com/ y miran si hay errores de PHP que revelen la estructura del sitio. Relacionado: automatizar tareas de monitoreo de seguridad.
3. No verificar los permisos después de aplicar CHMOD
Algunos hostings shared tienen comportamientos raros con permisos. Hacés chmod 600, pero después resulta que el usuario web no es el propietario del archivo y WordPress no puede leer wp-config.php. Siempre verificá que el sitio siga funcionando después de cambiar permisos. Si no funciona, probá con 640 como compromiso (propietario + grupo).
Preguntas Frecuentes
¿Qué información sensible contiene wp-config.php?
El nombre de la base de datos (DB_NAME), usuario MySQL (DB_USER), contraseña MySQL (DB_PASSWORD), salts de encriptación para cookies (AUTH_KEY, SECURE_AUTH_KEY, etc.), prefijo de tablas (TABLE_PREFIX), y constantes de configuración como WP_MEMORY_LIMIT. Todo eso en un archivo legible en texto plano.
¿Puedo renombrar wp-config.php para ocultarlo?
No. WordPress espera un archivo llamado wp-config.php; si lo renombrás a otra cosa, WordPress no lo encuentra y el sitio deja de funcionar. La «seguridad por oscuridad» no funciona acá.
¿Qué diferencia hay entre CHMOD 600 y 400?
CHMOD 600 da permisos de lectura y escritura al propietario. CHMOD 400 da solo lectura. WordPress no necesita escribir en wp-config.php después de instalación, así que ambos funcionan. Algunos prefieren 400 por ser más restrictivo, pero 600 es el estándar.
¿WordPress encontrará wp-config.php si lo muevo un nivel arriba?
Sí. WordPress busca wp-config.php en la carpeta actual, y si no lo encuentra, sube un nivel automáticamente. Es un comportamiento documentado y completamente compatible.
¿Debería monitorear cambios en wp-config.php?
Sí, especialmente si tu sitio es crítico o está en una industria sensible. Los atacantes a veces inyectan código en wp-config.php para mantener acceso después de que limpies el sitio. Plugins como Jetpack Security o WP Activity Log alertan sobre modificaciones no autorizadas.
Conclusión
Proteger wp-config.php requiere tres capas: mover el archivo fuera del document root (la más importante), aplicar reglas .htaccess para bloquear acceso directo, y configurar permisos CHMOD en 600. Si las implementás juntas, tenés defensa en profundidad: aunque falle una capa, las otras siguen en pie.
La mayoría de compromisos de WordPress empiezan por acceso a wp-config.php, porque todo lo demás fluye de ahí. Dedicá una hora ahora a estas configuraciones y evitás meses de dolor después.