El código HTTP 403 Forbidden indica que el servidor recibió y entendió la solicitud, pero se niega a autorizar el acceso. El archivo o la ruta pueden existir; la respuesta se relaciona con permisos, reglas de acceso, autenticación o alguna capa de seguridad.
La solución depende de quién genera el 403. Puede provenir de Apache, del sistema de archivos, de ModSecurity, de un plugin, de Cloudflare o de la propia aplicación. Cambiar permisos sin identificar la capa responsable puede empeorar el problema.
Diferencias entre 401, 403 y 404
- 401 Unauthorized: faltan credenciales válidas y el servidor solicita autenticación.
- 403 Forbidden: la solicitud fue comprendida, pero el acceso continúa denegado.
- 404 Not Found: el recurso solicitado no fue encontrado o el servidor decide no revelar su existencia.
La referencia de MDN sobre el estado 403 aclara que repetir la misma solicitud sin modificarla normalmente producirá el mismo resultado.
Primero determiná el alcance del problema
Probá distintas rutas y anotá el resultado:
- ¿El 403 afecta todo el dominio o una única carpeta?
- ¿Aparece sólo al guardar un formulario, subir un archivo o iniciar sesión?
- ¿Le ocurre a todos o solamente a una dirección IP?
- ¿Comenzó después de editar
.htaccess, instalar un plugin o activar una regla? - ¿La página de bloqueo muestra un identificador de Cloudflare o del firewall?
Esta clasificación evita modificar todo el sitio por un bloqueo que afecta una sola acción.
Revisar permisos y propietario de archivos
En un hosting Linux, los archivos suelen necesitar permisos de lectura para el servidor web y los directorios permiso de recorrido. Como referencia habitual se utilizan 644 para archivos y 755 para carpetas, pero la configuración concreta puede variar.
No apliques 777 de forma recursiva. Además de inseguro, no corrige un propietario incorrecto, una regla del servidor ni un bloqueo WAF. Si muchos elementos cambiaron de propietario después de una migración o restauración, solicitá que soporte revise la cuenta.
Directorio sin archivo índice
Si se solicita una carpeta que no contiene index.php, index.html u otro archivo índice y el listado de directorios está deshabilitado, Apache puede responder 403. Esto no significa que debas habilitar el listado: generalmente corresponde subir el archivo de inicio correcto o ingresar a una URL concreta.
Exponer el contenido completo de una carpeta puede revelar nombres de archivos, copias o información que no estaba destinada a visitantes.
Revisar reglas en .htaccess
Directivas como Require all denied, restricciones por IP, reglas de reescritura o protecciones de archivos pueden denegar acceso. Si el error comenzó inmediatamente después de editar .htaccess:
- Restaurá la copia anterior.
- Probá nuevamente la URL.
- Reincorporá los cambios de uno en uno.
- Revisá el registro de errores si aparece un 500 o 403.
No elimines definitivamente el archivo en un WordPress activo: sus enlaces permanentes dependen de reglas específicas. Si necesitás reconstruirlas, seguí la guía del .htaccess predeterminado de WordPress.
ModSecurity y el firewall de aplicaciones
ModSecurity inspecciona solicitudes y puede bloquear patrones asociados a ataques. Un falso positivo suele aparecer durante una acción específica: guardar código, enviar texto con determinadas palabras, subir un archivo o realizar una petición AJAX.
Anotá la URL, la fecha y hora exactas, la dirección IP y la acción realizada. Con esos datos el proveedor puede localizar el evento y evaluar la regla. Desactivar toda la protección de manera permanente no es una solución adecuada; si se confirma un falso positivo, conviene aplicar una excepción puntual.
Para entender la herramienta consultá qué es ModSecurity y cómo funciona como WAF.
403 generado por Cloudflare
Cuando el dominio está detrás de Cloudflare, la solicitud puede bloquearse antes de llegar al hosting. Revisá Seguridad → Eventos y buscá por hora, IP o Ray ID. Las causas posibles incluyen una regla personalizada, reglas administradas, control de bots, rate limiting o una regla de acceso.
No permitas una IP de forma global sin revisar qué protección omitiría. Si el bloqueo corresponde a una tarea administrativa legítima, una regla Skip limitada a la ruta, usuario autenticado o IP confiable suele ser más segura que una excepción general.
También verificá si el 403 ocurre con Cloudflare pausado o apuntando temporalmente al origen sólo durante una prueba controlada. No expongas permanentemente la IP del servidor para evitar el diagnóstico.
Plugins y reglas de WordPress
En WordPress, un plugin de seguridad puede limitar intentos de acceso, bloquear países, proteger archivos o impedir solicitudes consideradas sospechosas. Un plugin de caché, redirecciones o mantenimiento también puede influir.
Si tenés acceso al panel, revisá el registro del plugin y el cambio más reciente. Si no podés entrar, renombrar temporalmente la carpeta de un único plugin desde el Administrador de archivos puede servir como prueba, pero no desactives todos los componentes sin conservar una lista y un plan de reversión.
Protección por IP, país o contraseña
Un directorio protegido, una IP bloqueada en cPanel o una regla geográfica pueden devolver 403 de manera intencional. Confirmá si el visitante está usando una VPN, una conexión móvil o una IP nueva. Para restricciones geográficas, revisá cómo bloquear un país o región sin afectar tráfico legítimo.
Si sólo falla una conexión, compará desde otra red antes de cambiar el sitio. No compartas contraseñas ni desactives 2FA para resolver una denegación.
Hotlink Protection y acceso a imágenes
Cuando el 403 aparece únicamente en imágenes, videos o descargas incrustadas desde otro dominio, revisá Hotlink Protection. Una lista de referentes incompleta puede bloquear recursos utilizados por CDN, subdominios, correo HTML o aplicaciones externas.
Probá el archivo directamente y desde la página donde debería mostrarse. Agregá sólo los dominios necesarios y evitá permitir solicitudes sin referente si no son requeridas.
Registros útiles para el diagnóstico
El registro de acceso confirma la URL, método y código devuelto; el registro de errores suele indicar la directiva o módulo responsable. Apache recomienda consultar el error log durante las pruebas.
En cPanel, revisá Errores si está disponible. También pueden existir registros separados para ModSecurity, PHP, WordPress y Cloudflare. La ausencia de una solicitud en el servidor es una pista de que fue detenida antes de llegar al origen.
Información que conviene enviar al soporte
- URL exacta y método utilizado.
- Fecha y hora con zona horaria.
- Dirección IP pública del usuario afectado.
- Captura del mensaje y cualquier identificador visible.
- Acción realizada antes del error.
- Cambios recientes en plugins, permisos, DNS, WAF o
.htaccess.
Qué no conviene hacer
- No aplicar permisos 777 como solución general.
- No borrar
.htaccesssin copia ni análisis. - No desactivar permanentemente ModSecurity o Cloudflare.
- No permitir rangos amplios de IP por una sola solicitud bloqueada.
- No repetir muchas veces una acción si puede activar límites adicionales.
Resolver un 403 consiste en identificar la capa que deniega la solicitud y corregir la causa concreta. Con la URL, la hora, la IP y los registros adecuados, el diagnóstico suele ser mucho más rápido y seguro que modificar permisos o desactivar protecciones al azar.
