Los permisos seguros WordPress hardening no son un detalle opcional: un archivo con permisos 777 es una puerta abierta para que cualquier proceso del servidor lea tus credenciales de base de datos, inyecte código malicioso o deje un backdoor que vas a tardar semanas en detectar. La configuración estándar recomendada es 755 para carpetas y 644 para archivos, con wp-config.php en 600 como caso especial.
En 30 segundos
- Los permisos correctos en WordPress son 755 para directorios y 644 para archivos; wp-config.php necesita 600 o 440.
- Un permiso 777 permite que cualquier proceso del servidor escriba, lea y ejecute archivos, incluyendo scripts maliciosos subidos por atacantes.
- Con dos comandos SSH
findcorregís todos los permisos de instalación en menos de 30 segundos. - WPScan es la herramienta estándar para auditar configuraciones incorrectas desde línea de comandos; también existe el plugin WP Hardening para auditoría local.
- Las constantes
FS_CHMOD_DIRyFS_CHMOD_FILEen wp-config.php fuerzan los permisos correctos en cada actualización automática.
Qué son los permisos de archivos y por qué importan en WordPress
Un permiso de archivo en sistemas Linux es un conjunto de tres números que define quién puede leer (r), escribir (w) y ejecutar (x) un recurso. Los tres dígitos representan al propietario, al grupo y al resto del mundo. Un 7 significa rwx (todos los poderes), un 5 significa rx (leer y ejecutar, no escribir), un 4 solo lectura y un 6 lectura más escritura.
La auditoría de permisos de archivos y carpetas WordPress es uno de los primeros pasos en cualquier revisión de seguridad seria. ¿Por qué? Porque WordPress corre sobre un servidor compartido o VPS donde otros procesos también tienen vida propia. Si tu archivo wp-config.php tiene permisos 644, cualquier otro usuario del sistema puede leerlo. Ahí están tu nombre de base de datos, tu contraseña y tu prefijo de tabla. Suficiente para destruir el sitio en minutos.
Los riesgos concretos de permisos mal configurados, según Patchstack, van desde la lectura de credenciales hasta la inyección de PHP malicioso en archivos del core. No es teoría: es el vector de ataque detrás de gran parte de los hackeos de WordPress que llegan a los scanners de malware.
Permisos estándar recomendados: 755, 644 y otros valores
La documentación oficial de WordPress es bastante clara sobre esto. Los valores recomendados son:
| Tipo | Permiso | Notación simbólica | Motivo |
|---|---|---|---|
| Carpetas | 755 | rwxr-xr-x | El propietario escribe; el grupo y otros solo leen y ejecutan (navegan) |
| Archivos PHP/HTML | 644 | rw-r–r– | Solo el propietario escribe; todos leen |
| wp-config.php | 600 o 440 | rw——- o r–r—– | Solo el propietario puede acceder |
| .htaccess | 644 | rw-r–r– | Apache lo lee; solo el propietario escribe |
| wp-content/uploads | 755 | rwxr-xr-x | WordPress necesita escribir archivos subidos |
El 777 no aparece en esta tabla. No es un olvido.
Un directorio con permisos 777 (rwxrwxrwx) le da a cualquier proceso del servidor, a cualquier usuario del sistema y a cualquier script remoto que logre ejecutarse, permiso de escritura completa. En hosting compartido, eso incluye a los otros clientes del servidor. Ponele que tu vecino de hosting tiene un WordPress comprometido: con permisos 777 en tus carpetas, el script del atacante puede escribir en tu instalación sin haber nunca «entrado» a tu sitio.
Archivos y carpetas críticas: permisos especiales
No todos los archivos merecen el mismo nivel de paranoia. Estos son los que más importan:
wp-config.php
Este archivo contiene DB_NAME, DB_USER, DB_PASSWORD, las claves secretas de autenticación y el prefijo de tabla. Si un atacante lo lee, tiene todo lo que necesita para hacer un dump completo de tu base de datos. El permiso correcto es 600 (solo el propietario lee y escribe). En algunos servidores donde el proceso web y el propietario del archivo son el mismo usuario, 400 o 440 también zafan.
wp-content/uploads
Esta carpeta necesita ser escribible porque ahí van las imágenes que subís, los PDFs adjuntos y los archivos temporales de plugins. El permiso 755 es el correcto: WordPress puede escribir, pero los visitantes y otros procesos solo pueden leer. Eso sí: nunca debería ejecutarse PHP desde esta carpeta. Si tu servidor ejecuta scripts PHP desde uploads, cualquier imagen con extensión cambiada se vuelve un webshell. Un bloqueo vía .htaccess en esa carpeta es buena práctica adicional. Ya lo cubrimos antes en estrategias de seguridad en capas.
.htaccess
Con 644 alcanza. Apache lo necesita leer para aplicar las reglas de reescritura (los permalinks), pero no necesita escribirlo. WordPress sí escribe en .htaccess cuando cambiás la estructura de permalinks, así que el propietario necesita permisos de escritura. El resto del mundo, no.
Riesgos de una configuración incorrecta de permisos
Hay cuatro escenarios concretos que explican por qué esto no es algo que se puede dejar para después:
- Lectura de wp-config.php con 644 o 666: cualquier usuario del servidor obtiene credenciales de base de datos. En hosting compartido, eso incluye a otros clientes del mismo servidor.
- Escritura en archivos del core con 666 o 777: un script malicioso puede modificar index.php, functions.php de un tema activo o cualquier plugin para insertar backdoors que sobreviven a limpiezas superficiales.
- Ejecución de PHP en /uploads con 777: el atacante sube un archivo aparentemente inofensivo (una imagen con código PHP embebido), le cambia la extensión o usa una vulnerabilidad de subida de archivos, y ya tiene ejecución remota de código.
- Permisos 777 en wp-admin: no tiene ningún sentido operativo y abre escritura a todos los procesos del servidor sobre los archivos administrativos de WordPress.
¿El escenario más común en la práctica? Un desarrollador que necesitó darle permisos de escritura temporales a una carpeta para instalar un plugin, puso 777 «por las dudas» y se olvidó de revertirlo. Pasaron seis meses. Un scanner de vulnerabilidades lo encontró antes de que el dueño del sitio lo notara.
Auditar permisos con WPScan y otras herramientas
WPScan es el scanner de seguridad de referencia para WordPress. Está escrito en Ruby y tiene una base de datos de vulnerabilidades conocidas que se actualiza constantemente. Para auditar un sitio propio desde línea de comandos:
wpscan --url https://tu-sitio.com --enumerate
El flag --enumerate activa la detección de plugins vulnerables, temas, usuarios y configuraciones inseguras. Según la documentación de uso de WPScan, el scanner también reporta versiones desactualizadas del core, plugins sin mantener y configuraciones problemáticas del servidor.
Ojo: WPScan es para auditar sitios propios o con autorización explícita por escrito. Usarlo sobre sitios ajenos sin permiso es ilegal en la mayoría de las jurisdicciones, independientemente de las intenciones.
Para auditoría local sin SSH, el plugin WP Hardening hace una revisión de permisos directamente desde el dashboard de WordPress y lista qué archivos tienen configuraciones riesgosas. Es más limitado que WPScan pero sirve si no tenés acceso a terminal.
Cambiar permisos con CHMOD: comandos SSH paso a paso
Si tenés acceso SSH (lo cual deberías tener en cualquier hosting decente como donweb.com), dos comandos resuelven toda la instalación de una vez:
find /ruta/a/tu/wordpress -type d -exec chmod 755 {} \;
find /ruta/a/tu/wordpress -type f -exec chmod 644 {} \;
El primero busca todos los directorios (-type d) y aplica 755. El segundo hace lo mismo con archivos (-type f) y aplica 644. Después corregís wp-config.php de forma específica: En blindar tu servidor contra ataques profundizamos sobre esto.
chmod 600 /ruta/a/tu/wordpress/wp-config.php
Subís todo y listo. En un servidor mediano con 500 archivos, esto tarda menos de cinco segundos.
Si no tenés SSH, FileZilla y la mayoría de los clientes FTP tienen la opción de clic derecho «Permisos de archivo» donde podés ingresar el valor numérico manualmente. Es más lento pero funciona. El problema es que tenés que hacerlo carpeta por carpeta o archivo por archivo, lo cual en una instalación con plugins es una tarde entera de trabajo (sí, en serio).
Una advertencia importante: algunos plugins necesitan permisos específicos para funcionar. Si después de aplicar 644 a todos los archivos algún plugin deja de escribir logs o fallan las actualizaciones automáticas, revisá si ese plugin necesita que algún directorio específico sea 755 o que algún archivo de configuración sea escribible.
Automatizar permisos con FS_CHMOD_DIR y FS_CHMOD_FILE
WordPress tiene dos constantes que podés definir en wp-config.php para que los permisos se apliquen automáticamente cada vez que WordPress escribe archivos, instala plugins o aplica actualizaciones:
define('FS_CHMOD_DIR', 0755);define('FS_CHMOD_FILE', 0644);
El prefijo 0 es importante: en PHP, los números octales van con ese prefijo. Sin él, 755 se interpreta como decimal y el permiso resultante es incorrecto. Es un error silencioso que no genera ningún aviso pero deja permisos completamente distintos a los esperados.
La ventaja de este enfoque es que cada actualización automática del core, cada instalación de plugin y cada actualización de tema respeta estos permisos. Sin las constantes, WordPress usa los valores por defecto del sistema, que en algunos servidores son permisivos por compatibilidad. Te puede servir nuestra cobertura de controlar acceso en WooCommerce.
La limitación: estas constantes controlan lo que WordPress escribe, pero no retroactivamente corrigen lo que ya existe. Si ya tenés archivos con 777, agregar las constantes no los cambia. Primero corrégis con los comandos find, después agregás las constantes para que se mantenga.
Verificar propietario y grupo: usuario vs. grupo
Los permisos numéricos son solo la mitad de la historia. El otro factor es quién es el propietario del archivo y a qué grupo pertenece. En un servidor Linux, cuando el proceso web (Apache o Nginx, corriendo como www-data o apache) intenta escribir en un archivo del que es propietario un usuario diferente, los permisos del grupo son los que determinan si puede o no.
Para ver el propietario de los archivos:
ls -la /ruta/a/tu/wordpress
La salida muestra algo así: -rw-r--r-- 1 tu_usuario www-data 8423 Jan 12 14:30 wp-config.php
Si wp-content/ y sus subdirectorios son propiedad de www-data (el usuario del servidor web), WordPress puede escribir en ellos con permisos 755 sin problemas. Si son propiedad de tu usuario de sistema y el grupo es www-data, necesitás asegurarte de que los permisos de grupo incluyan escritura donde corresponde (lo cual vuelve a justificar 755 para carpetas, no 700).
Para cambiar el propietario y grupo en toda la instalación:
chown -R tu_usuario:www-data /ruta/a/tu/wordpress
El error más común acá es que todo queda propiedad de root después de una migración o instalación manual. Con root como propietario y www-data como grupo, WordPress no puede escribir archivos aunque los permisos sean 755 (porque el grupo solo tiene rx, no w). Resultado: actualizaciones que fallan silenciosamente, imágenes que no se suben, cache que no se genera.
Errores comunes al configurar permisos en WordPress
Poner 777 «para que funcione» y olvidarse de revertirlo
Es el error más frecuente. Hay un problema con la subida de archivos, el plugin de cache no puede escribir, el instalador del tema falla. La solución rápida es chmod 777. El problema se resuelve. Nadie anota que hay que revertir el permiso. Seis meses después, un scanner de seguridad o directamente un atacante lo encuentra. La corrección correcta es diagnosticar por qué el proceso web no puede escribir (generalmente es un problema de propietario/grupo) en vez de abrir permisos a todo.
Aplicar 600 a wp-config.php cuando el servidor web necesita leerlo
En algunos configuraciones de servidor donde el usuario del proceso web y el propietario del archivo son distintos, un 600 en wp-config.php hace que WordPress no pueda leer su propio archivo de configuración. El sitio da pantalla blanca o error de conexión a la base de datos. La solución es 640 (propietario lee/escribe, grupo solo lee) cuando el grupo es el usuario del servidor web, o revisar que el propietario sea el mismo usuario que corre PHP. Lo explicamos a fondo en restringir acceso a formularios sensibles.
No bloquear la ejecución de PHP en wp-content/uploads
Los permisos 755 en uploads son necesarios para que WordPress pueda escribir archivos. Pero eso no significa que PHP deba ejecutarse desde esa carpeta. Un .htaccess en wp-content/uploads con este contenido bloquea la ejecución de scripts:
php_flag engine off
O en Nginx, una regla de location que devuelve 403 para archivos PHP. Sin esta capa adicional, un atacante que logre subir un archivo PHP (por una vulnerabilidad en el formulario de subida de medios o en un plugin) puede ejecutarlo directamente desde la URL.
Preguntas Frecuentes
¿Cuáles son los permisos correctos en WordPress?
Los permisos recomendados por la documentación oficial de WordPress son 755 para todos los directorios y 644 para todos los archivos. La excepción es wp-config.php, que debería estar en 600 o 440 para restringir el acceso solo al propietario. El archivo .htaccess también va en 644.
¿Cómo auditar los permisos de mi WordPress?
Desde SSH, el comando find /ruta/wordpress -type f ! -perm 644 lista todos los archivos que no tienen el permiso estándar. Para directorios: find /ruta/wordpress -type d ! -perm 755. Alternativamente, WPScan con el flag --enumerate detecta configuraciones inseguras, o podés usar el plugin WP Hardening para una revisión desde el dashboard sin necesidad de terminal.
¿Por qué no debo usar permisos 777 en WordPress?
El permiso 777 otorga lectura, escritura y ejecución a cualquier proceso del servidor, cualquier usuario del sistema y cualquier script que logre correr en el host. En hosting compartido, esto incluye a otros clientes del servidor. Un atacante que comprometa cualquier sitio en el mismo servidor puede usar permisos 777 para escribir backdoors en tu instalación sin necesidad de atacarte directamente.
¿Qué permisos necesita wp-config.php?
wp-config.php debería tener permisos 600 (solo el propietario puede leer y escribir) o 440 (propietario y grupo solo lectura). Este archivo contiene las credenciales de la base de datos, las claves secretas de autenticación y el prefijo de tabla. Con permisos 644, cualquier usuario del sistema puede leerlo. El permiso exacto a usar depende de la configuración de usuario/grupo del servidor.
¿Cómo cambiar permisos con CHMOD en WordPress?
Desde SSH, dos comandos cubren toda la instalación: find /ruta/wordpress -type d -exec chmod 755 {} \; para directorios y find /ruta/wordpress -type f -exec chmod 644 {} \; para archivos. Después aplicás chmod 600 wp-config.php de forma específica. Si no tenés SSH, FileZilla y otros clientes FTP permiten cambiar permisos con clic derecho en cada archivo o carpeta.
Conclusión
Configurar los permisos seguros WordPress hardening correctamente es una tarea de 30 minutos que elimina uno de los vectores de ataque más explotados en instalaciones comprometidas. Dos comandos SSH, una línea en wp-config.php para wp-config.php específicamente, y las constantes FS_CHMOD_DIR y FS_CHMOD_FILE para que no se revierta en cada actualización.
Lo que más me llama la atención al revisar instalaciones de WordPress en producción es que el 777 casi nunca es intencional: alguien lo puso para resolver un problema puntual, lo dejó, y el sistema nunca protestó. Hasta que protestó.
La auditoría con WPScan o con los comandos find debería estar en el checklist de cualquier instalación nueva y en las revisiones periódicas de seguridad, junto con la revisión de plugins desactualizados y la configuración de autenticación de dos factores. Son capas de protección independientes: que una esté bien no compensa que la otra esté mal.