Error 403 en WordPress: permisos, firewall y otras causas

Un error 403 significa que el servidor o una capa de seguridad rechaza el acceso a una ruta; no indica por sí solo que WordPress esté roto. La respuesta puede venir de permisos, reglas del servidor, firewall, CDN o de un plugin. Primero descubre quién emite el 403 y si solo afecta a una IP o a una operación, antes de cambiar permisos o desactivar defensas.

Delimita la ruta y la capa que responde

1. Anota URL exacta, hora, IP de prueba, código HTTP y acción: abrir una página, entrar en wp-admin, guardar una entrada o subir un archivo.
2. Prueba con una sesión privada y, si es seguro, desde otra red. Compara también una página que funciona.
3. Revisa cabeceras y logs del CDN/WAF, servidor web y WordPress en ese orden. Una página de bloqueo con identificador de regla es distinta de una negación por permisos del sistema.

Si el 403 aparece únicamente al guardar una entrada, la petición del editor puede estar bloqueada por un WAF. Si ocurre en una carpeta concreta tras una migración, revisa propietario, permisos y reglas de acceso. Si solo tu IP ve el fallo, busca un bloqueo de seguridad o reputación; no desactives el firewall para todos los visitantes.

Actúa según la evidencia

Cuando una regla del WAF produce un falso positivo, pide al administrador revisar su ID, ruta y cuerpo de petición. Una excepción debe ser estrecha y registrarse; excluir todo /wp-admin/ crea otro problema. Si el log marca permission denied, compara el propietario y los modos de la ruta afectada con una sana. La guía de permisos explica por qué un cambio recursivo a 777 no es solución. Si la ruta está protegida de forma intencionada —por ejemplo, archivos privados— no la abras para «hacer desaparecer» el 403.

Ejemplo de diagnóstico: solo una llamada al guardar bloques recibe 403; la portada y otros editores funcionan, y el WAF registra el identificador de la regla a la misma hora. Prueba una excepción limitada para esa regla en staging o durante una ventana controlada y comprueba que sigue bloqueando solicitudes claramente indebidas. Es una hipótesis de trabajo, no un caso documentado de IDEIHOSTING.

Verifica y documenta

Repite la acción original desde las redes afectadas, comprueba que otras rutas protegidas siguen cerradas y revisa los registros de seguridad. Si solo falla el acceso administrativo, sigue el diagnóstico de wp-admin. Si el código real es 500, usa la guía del error 500. Puedes solicitar revisión técnica con la hora, URL y regla, sin enviar contraseñas por el formulario.