Abres el panel de seguridad de WordPress y aparece una alerta sobre wp-config.php: antes de cambiar permisos o copiar reglas, identifica el servidor, crea una copia de seguridad y aplica una sola medida compatible para evitar errores 403, 500 o una web inaccesible.
✉
¿Quieres más información? Escríbenos y te orientamos
Wp-config.php debe bloquearse por HTTP
Un archivo .php está protegido frente al acceso web directo cuando su dirección devuelve 403 Forbidden o 404 Not Found , sin mostrar ni descargar texto. WordPress necesita el archivo para funcionar, pero ningún visitante debe poder pedirlo por URL.
Un código 200 exige actuar rápido
Una respuesta HTTP 200 para /wp-config.php indica que el servidor ha aceptado la petición y exige actuar con rapidez. No compartas capturas ni descargues el contenido para comprobarlo: pide al hosting que revise el acceso y cambia primero la contraseña de la base de datos si existe una exposición confirmada. La guía de OWASP Secrets Management Cheat Sheet recomienda rotar los secretos afectados.
Tres riesgos que no son el mismo
Bloquear una URL protege frente al acceso desde la web, mientras que los permisos de archivos o CHMOD limitan quién puede leer el archivo dentro del servidor. Las copias de seguridad y Git son otra vía de exposición: una copia o un repositorio público puede filtrar las credenciales aunque la URL principal devuelva 403. Además, WP_DEBUG activo puede mostrar rutas internas y mensajes útiles para un atacante.
✉
¿Quieres más información? Escríbenos y te orientamos
Identifica tu servidor antes de copiar una regla
Las reglas para denegar acceso solo funcionan si coinciden con el programa que atiende la web: Apache HTTP Server y LiteSpeed suelen leer .htaccess, mientras que Nginx nunca lo lee.
Señales útiles en cPanel y plesk
El nombre «LiteSpeed Web Server» en cPanel suele indicar compatibilidad con reglas Apache en .htaccess, pero el texto «nginx» en Plesk no basta para decidir porque puede combinar Nginx y Apache. Comprueba siempre la respuesta HTTP tras realizar el cambio, no solo el nombre mostrado en el panel. Los plugins de seguridad pueden alertar sobre ajustes débiles, pero no siempre controlan las reglas del servidor.
Elige una vía según tu alojamiento
Entorno ¿Lee .htaccess? Medida inicial segura Quién actúa Compartido con Apache Sí Copia y regla en .htaccess Tú, con reversión LiteSpeed con cPanel Sí, normalmente Regla compatible y prueba HTTP Tú o soporte Nginx gestionado No Solicitar bloqueo al proveedor Soporte VPS propio Depende Editar la capa activa Administrador Docker, Bedrock o variables No es la decisión central Revisar el proyecto Equipo técnico WordPress multisite Depende Consultar antes de mover archivos Soporte o administrador
Para una primera web, confirma el servidor, guarda una copia del ajuste que tocarás y añade una sola capa de bloqueo compatible. Si Apache o LiteSpeed leen .htaccess, una regla pequeña puede bastar; si Nginx controla el sitio, solicita el cambio al hosting. No dupliques reglas ni plugins de seguridad para el mismo fin.
Aplica solo la capa compatible con tu caso
En una instalación estándar con Apache o LiteSpeed, añade al final de .htaccess, únicamente si el hosting confirma compatibilidad y tras guardar una copia fuera de la carpeta pública, esta regla:
<Files "wp-config.php">
Require all denied
</Files>
Los permisos no tienen un número mágico
CHMOD expresa permisos con tres cifras: propietario, grupo y resto de usuarios. 400 permite leer solo al propietario, 440 permite leer al propietario y al grupo, y 600 permite leer y escribir solo al propietario. Un valor entre 400 y 600 puede ser correcto, pero depende del usuario con que PHP ejecuta WordPress; cambiar directamente a 600 puede causar permisos denegados, un error 500 o una web en blanco.
Moverlo puede servir, pero no es el inicio
WordPress puede cargar wp-config.php desde un nivel por encima de la carpeta donde está instalado, lo que puede reducir la exposición en instalaciones estándar. Sin embargo, no muevas el archivo en WordPress gestionado, Docker, Bedrock, multisite o proyectos con variables de entorno sin revisar su documentación, porque puede no ser la fuente real de las credenciales y el despliegue automático podría romperse.
Decisión segura en cuatro comprobaciones
1. Identifica
2. Copia
3. Bloquea
4. Verifica
Backups y git también guardan secretos
Busca en el administrador de archivos variantes como .php~, .old, .txt y wp-config.php.bak. Borra las que no necesites después de confirmar que la web funciona y no subas credenciales reales a un repositorio Git público. Las copias de seguridad deben permanecer fuera de una carpeta accesible por URL y contar con acceso restringido.
✅
Nuestra recomendación
Una caja de seguridad para discos puede ser útil si guardas copias de WordPress fuera del hosting. Protege el soporte físico, pero no sustituye el cifrado ni una contraseña segura.
Reduce el riesgo de acceso físico a un disco con backups de la web.
Ayuda a separar las copias locales de ordenadores compartidos o zonas comunes.
Permite guardar el disco desconectado tras comprobar que la copia se restauraría.
Ver disponibilidad →
La seguridad de wp-config.php no depende solo de bloquear su URL: el archivo suele contener el nombre de la base de datos, el usuario, la contraseña de la base de datos, el prefijo de tablas y las claves de seguridad de WordPress, incluidas las salts de autenticación. Si hubo una exposición confirmada, rota las credenciales de la base de datos y genera nuevas claves y salts, ya que estas invalidan las cookies de sesión existentes y obligan a iniciar sesión de nuevo.
Revisa también constantes como DISALLOW_FILE_EDIT, si encajan con tu operación, y mantén WP_DEBUG desactivado en producción para no revelar información técnica en pantalla.
Dentro de los permisos CHMOD de WordPress, 640 también puede ser apropiado: concede lectura y escritura al propietario, lectura al grupo y ningún permiso al resto de usuarios. Es útil cuando el proceso PHP pertenece al grupo autorizado del archivo, pero no al mismo usuario propietario; en ese caso, 600 podría impedir que WordPress lea wp-config.php. Antes de cambiar permisos, consulta el propietario y el grupo desde el administrador de archivos, SSH o soporte técnico, anota el valor actual y prueba portada y administración tras el cambio.
El objetivo no es usar el número más restrictivo, sino permitir exclusivamente el acceso que necesita PHP.
En un VPS con Nginx que administras tú, el bloqueo debe situarse en el bloque server del sitio, no en .htaccess. Una regla mínima es location = /wp-config.php { return 404; }, que responde sin entregar el archivo y evita afectar a otras rutas. Si WordPress está instalado en un subdirectorio, adapta la ubicación al prefijo real de la instalación.
Guarda antes una copia del virtual host, valida la sintaxis con nginx -t y recarga Nginx solo si la validación es correcta. Después comprueba la URL con cabeceras HTTP y revisa el registro de errores si el sitio deja de responder.
✉
¿Quieres más información? Escríbenos y te orientamos
Verifica el bloqueo y revierte sin pánico
La comprobación segura consiste en pedir solo las cabeceras HTTP de wp-config.php y confirmar un 403 o 404 mediante curl -I https://tudominio.es/wp-config.php, ya que -I solicita cabeceras y no el cuerpo del archivo.
Un 403 puede ser bueno o malo
Un 403 es correcto únicamente para la petición concreta a /wp-config.php. Si la portada, /wp-admin/, la API REST, las imágenes o las hojas CSS también devuelven 403, la regla es demasiado amplia o entra en conflicto con otra medida. Vuelve atrás antes de tocar nada más y evita activar el endurecimiento de archivos en dos plugins de seguridad a la vez.
Reversión en tres movimientos
Si aparece un error 500, restaura la copia de .htaccess o pide al soporte que revierta la configuración Nginx. Si cambiaste CHMOD justo antes de la caída, devuelve el permiso anterior anotado en tu copia y revisa los registros de errores de PHP, Apache o Nginx. Haz una modificación cada vez, prueba la portada y la administración, y no adivines si no tienes acceso a los logs.
No apliques cambios manuales de CHMOD, .htaccess, Nginx o traslado del archivo si usas WordPress gestionado, Docker, Bedrock, multisite, variables de entorno o no tienes acceso y copia de seguridad verificable. Consulta primero la documentación del proveedor o su soporte. Si el servidor ya bloquea correctamente el acceso web, no añadas reglas duplicadas solo por precaución.
La recomendación práctica es bloquear la URL únicamente en la capa que controla tu hosting, conservar una copia para volver atrás y comprobar un 403 o 404 mediante cabeceras. Los permisos CHMOD y mover el archivo son capas opcionales, no obligaciones universales. Revisa también backups, Git y archivos temporales, porque una copia con credenciales reales puede anular la protección del archivo principal.
Preguntas frecuentes
¿Cómo proteger wp-config.php sin romper WordPress?
Protege wp-config.php con una regla compatible con tu servidor y verifica que su URL devuelve 403 o 404. Haz una copia del ajuste previo y cambia una sola cosa cada vez para poder revertirla si aparece un error 500.
¿Qué permisos debe tener wp-config.php?
Los permisos pueden estar entre CHMOD 400, 440 y 600 según el propietario del archivo y el usuario con que PHP ejecuta WordPress. No cambies a 600 sin confirmar ese dato en el hosting, porque puede impedir a WordPress leer su propia configuración.
¿Puedo mover wp-config.php fuera de la raíz?
Sí, una instalación estándar puede cargarlo desde un nivel por encima de la carpeta de WordPress. No lo muevas en multisite, Docker, Bedrock, hosting gestionado o proyectos con variables de entorno sin revisar antes su estructura.
¿Un plugin puede ocultar o proteger wp-config.php?
Un plugin puede detectar permisos débiles, crear reglas o añadir un WAF, pero no siempre controla Nginx ni las políticas del hosting. Instala un solo plugin de seguridad con esa función y verifica el resultado con un 403 o 404.
¿Cuánto cuesta proteger wp-config.php?
El bloqueo básico mediante una regla del servidor puede costar 0 euros si tu hosting permite hacerlo o lo aplica por defecto. Los planes de plugins de seguridad cambian según el proveedor, pero pagar un plugin no arregla una copia expuesta en Git, un backup público o una regla Nginx ausente.
