Permisos de ficheros en WordPress: los números correctos

«Ponlo todo a 777 y funciona.» Es el consejo más repetido de los foros y la causa de una parte de las webs que acabamos limpiando. Los permisos de ficheros son de esas cosas que no se ven, no dan error mientras están mal y solo se notan el día que alguien sube un fichero donde no debería poder.

Esta guía te da los números correctos, cómo comprobarlos sin ser administrador de sistemas y qué significa realmente cada uno.

Qué es un permiso, en 30 segundos

En un servidor Linux cada fichero tiene tres grupos de permisos: para el dueño, para el grupo y para el resto del mundo. Cada grupo puede leer (4), escribir (2) y ejecutar (1). Se suman:

7 = leer + escribir + ejecutar
6 = leer + escribir
5 = leer + ejecutar
4 = solo leer

Por eso 755 significa: el dueño puede todo, el grupo y el resto solo leer y entrar en la carpeta. Y 777 significa cualquiera puede escribir. En un servidor compartido, «cualquiera» incluye a procesos que no son tuyos.

Los números correctos para WordPress

Elemento	Permiso	Por qué
Carpetas en general	`755`	Hay que poder entrar y listar, no escribir desde fuera
Ficheros en general	`644`	Se leen y los ejecuta PHP; nadie más los modifica
`wp-config.php`	`640` o `600`	Contiene las credenciales de la base de datos: cuanto menos accesible, mejor
`wp-content/uploads`	`755` (ficheros `644`)	WordPress escribe aquí; el usuario del servidor web debe ser el dueño
`.htaccess`	`644`	WordPress lo reescribe al cambiar los enlaces permanentes
Cualquier cosa	~~`777`~~	Nunca. Si algo «solo funciona con 777», el problema es el dueño del fichero, no el permiso

El problema real no suele ser el número: es el dueño

Este es el punto que casi todas las guías se saltan. Un fichero tiene un propietario y un grupo. Si los ficheros pertenecen a un usuario distinto del que ejecuta PHP, WordPress no puede escribir, y entonces alguien «lo arregla» poniendo 777 para que escriba todo el mundo.

La solución correcta es que los ficheros pertenezcan al usuario del sitio y PHP se ejecute como ese mismo usuario. En un hosting decente ya viene así. Si tu proveedor ejecuta PHP como un usuario genérico compartido entre clientes, tienes un problema de arquitectura que ningún permiso arregla: lo explicamos en hosting compartido, VPS o servidor gestionado.

Cómo comprobarlo sin ser técnico

Desde el panel de tu hosting

Casi todos los gestores de archivos muestran una columna «Permisos». Ordena por ella y busca cualquier cosa que ponga 777 o 666. Si aparece algo, anótalo antes de cambiarlo.

Con la herramienta de estado de WordPress

En Herramientas → Salud del sitio → Información → Sistema de archivos, WordPress te dice si puede escribir en cada carpeta. Si dice que puede escribir en el directorio raíz o en wp-admin, tienes más permiso del necesario.

Por línea de comandos, si tienes acceso

find . -type d -perm -o+w
find . -type f -perm -o+w

Lista carpetas y ficheros donde puede escribir «el resto del mundo». En una instalación sana, esa lista está vacía.

Cómo corregirlos de golpe

Si tienes acceso por consola, desde la raíz de la web:

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 640 wp-config.php

Antes de ejecutar nada: haz una copia de seguridad completa y comprueba que puedes restaurarla. Un cambio masivo de permisos mal hecho deja la web en blanco. Qué debe incluir esa copia lo tienes en copias de seguridad de una web.

Si no tienes consola, tu proveedor puede hacerlo en dos minutos. Pídeselo por escrito indicando exactamente estos números: es una petición habitual y no debería costarte nada.

Lo que unos permisos correctos evitan de verdad

No hacen tu web invulnerable, pero sí limitan el daño cuando algo falla, que es de lo que va el endurecimiento:

Si un plugin tiene un fallo que permite subir ficheros, con uploads bien configurado y ejecución de PHP desactivada en esa carpeta, el fichero subido no se puede ejecutar.
En un servidor compartido mal aislado, unos permisos estrictos impiden que el problema de la web de al lado se convierta en el tuyo.
Con wp-config.php restringido, un fallo que permita leer ficheros arbitrarios no entrega directamente la contraseña de tu base de datos.

El complemento imprescindible: que uploads no ejecute PHP

La carpeta de subidas debe aceptar imágenes y PDF, no código. En Apache, un .htaccess dentro de wp-content/uploads:

<Files *.php>
  Require all denied
</Files>

En Nginx se hace en la configuración del sitio. Esta medida sola corta en seco el método de persistencia más habitual que encontramos: un fichero PHP disfrazado de imagen dentro de las subidas.

Y después

Los permisos son una pieza de la configuración segura de la web, junto con desactivar el editor de archivos del escritorio y las cabeceras de seguridad. Los tres van en la misma sesión de trabajo: media hora bien empleada.

Si al revisar encuentras ficheros con fechas de modificación raras o nombres que no reconoces en uploads, para y no borres nada todavía: eso ya no es configuración, es un posible incidente, y lo primero es conservar las evidencias.

La referencia oficial, por si tu proveedor discute los números, está en el manual de administración avanzada de WordPress.

Seguir leyendo en esta sección

Ver todo en Endurecer tu web → · Mapa completo del sitio