Error 403 Forbidden: cómo identificar qué bloquea tu sitio
Actualizado hace 3 días
El error 403 Forbidden indica que se rechazó el acceso a una dirección de tu sitio. Para resolverlo, comprobá si afecta a todos los visitantes o solo a una conexión, y si el bloqueo proviene de Cloudflare, de la aplicación o de una regla del servidor.
Si solo estás visitando una web ajena, verificá la dirección y avisale a su administrador. Los cambios de archivos, permisos y reglas de seguridad de esta guía requieren acceso al sitio o al hosting.
Primero delimitá el problema
La misma URL puede dar pistas distintas según la conexión, la sesión iniciada o la acción que intentás realizar. Guardá el mensaje completo antes de cambiar configuraciones.
Copiá la URL exacta y anotá la fecha, hora y zona horaria del error.
Probá la página de inicio y otra dirección que normalmente funcione.
Probá la URL afectada en una ventana privada. Si requiere iniciar sesión, usá una cuenta autorizada.
Probá desde otra conexión, por ejemplo datos móviles, para comparar el resultado.
Registrá si el error aparece al abrir la página o al realizar una acción, como guardar un cambio o enviar un formulario.
Una prueba que funciona desde otra red es una pista de un bloqueo por conexión o IP, no una prueba definitiva de la causa. Usala para investigar el evento; no para continuar intentando una operación que el sistema está bloqueando.
Lo que observás
Por dónde empezar
Una página de bloqueo de Cloudflare, a veces con Ray ID
Eventos de seguridad de Cloudflare.
La web abre, pero guardar o enviar un formulario devuelve 403
Reglas de seguridad y registros de la aplicación.
Solo tu conexión o un visitante recibe el error
Restricciones por IP, sesión, país o frecuencia de solicitudes.
Todos reciben 403 después de subir o mover el sitio
Carpeta del dominio, archivo de inicio, permisos y reglas de acceso.
Solo falla una carpeta o una zona privada
Si esa dirección debe permitir acceso público.
Revisá el caso que coincide con tu error
Un 403 es el resultado de una restricción. El registro del evento permite distinguir una protección legítima de una regla que está bloqueando una acción válida.
Veo una página de bloqueo de Cloudflare
Si aparece un Ray ID, copialo junto con la hora del error. Ese identificador permite buscar la solicitud en los eventos de seguridad del dominio.
Que una respuesta haya pasado por Cloudflare no demuestra que Cloudflare originó el 403. Tampoco una página sin su logotipo permite descartarlo por completo: si no encontrás el evento, necesitamos revisar también el servidor de origen.
El sitio abre, pero recibo 403 al guardar o enviar un formulario
Una regla de seguridad puede rechazar el contenido de una solicitud, aunque permita abrir el resto de la web. También puede existir una restricción propia de WordPress o de la aplicación.
Anotá la página y la acción exacta que dispara el error.
Si estás editando contenido, conservá una copia privada antes de repetir la prueba.
Probá una sola vez con contenido de prueba sin datos sensibles, si eso no genera pedidos ni otras operaciones reales.
Enviános la hora y el resultado para buscar la solicitud en los registros del servidor.
Si usás nuestro plugin Imunify Security, sus eventos también pueden aportar información. El código 403 por sí solo no identifica a ModSecurity, Imunify ni a un plugin concreto.
No elimines contenido válido de forma permanente para «hacerlo pasar». Si se confirma un falso positivo, corresponde ajustar la regla para la operación necesaria.
Solo una IP, un usuario o una conexión recibe 403
Las reglas de acceso pueden limitar una IP o un grupo de solicitudes. En una sección privada, también puede ser correcto que una cuenta sin permisos no pueda ingresar.
Si cambia el resultado según la red, guardá la IP pública de la conexión afectada y compartila de forma privada con soporte.
Si cambia según el usuario, revisá sus permisos dentro de la aplicación.
Si usás un plugin de seguridad, revisá sus eventos y las restricciones configuradas recientemente.
Si usás Cloudflare, contrastá el momento del error con sus eventos antes de modificar una regla.
Si una persona autorizada quedó bloqueada, la corrección debe limitarse al acceso que necesita. Desactivar todas las protecciones del sitio dificulta encontrar la causa y amplía el alcance del cambio.
Todos reciben 403 después de subir o migrar archivos
El dominio debe apuntar a la carpeta correcta y el servidor debe poder leer los archivos necesarios para mostrar la página.
Comprobá la carpeta raíz del dominio afectado; un dominio adicional puede usar una carpeta distinta de public_html.
Verificá que el archivo de inicio esperado por la aplicación, como index.php o index.html, esté en esa carpeta y que la subida haya terminado.
Compará los permisos y las reglas de acceso con los que tenía el sitio antes de la migración.
Si falta el archivo de inicio y el listado de directorios está deshabilitado, el servidor puede rechazar la apertura de la carpeta. Recuperá el archivo correcto de tu sitio; habilitar el listado de archivos no reemplaza una página de inicio.
Si el mensaje indica que el servidor no puede leer .htaccess, enviános el error. Hay que revisar tanto los permisos como el propietario y las carpetas de la ruta, no solo el archivo nombrado.
El error empezó al cambiar .htaccess o las reglas de acceso
Una regla de .htaccess puede prohibir una ruta o una IP. Si conocés el cambio que produjo el problema, recuperá la versión previa de esa regla después de guardar una copia del archivo actual.
No borres todo el archivo para probar: puede contener restricciones de seguridad, redirecciones y configuración de la aplicación. El archivo también puede estar oculto en el administrador de archivos.
Si el sitio es WordPress, nuestra referencia de reglas habituales de WordPress ayuda a comparar, pero no debe reemplazar a ciegas una configuración personalizada o de multisitio.
Solo una carpeta o un archivo privado devuelve 403
La denegación puede ser intencional. Una carpeta de respaldos, un archivo de configuración o una sección reservada no tiene por qué estar disponible desde el navegador.
Confirmá si esa dirección debe ser pública antes de cambiar permisos. Si solo necesitás descargar un backup propio, hacelo desde la herramienta de respaldos o el administrador de archivos, sin volver público el directorio.
Recibo el mensaje de Imunify360 bot-protection
El aviso Access denied by Imunify360 bot-protection. IPs used for automation should be whitelisted indica que la protección contra bots bloqueó la conexión, habitualmente por una automatización que envía muchas solicitudes en poco tiempo.
Enviános la IP y la hora del bloqueo para revisarla y liberarla, y ajustá la automatización para que distribuya las solicitudes en el tiempo.
La web abre en el navegador, pero una API o un crawler recibe 403
Las reglas de seguridad evalúan la frecuencia de las solicitudes, la IP y las características del cliente, no solo las credenciales: una integración o un crawler pueden ser bloqueados aunque el acceso con el navegador funcione.
Reuní el endpoint, el método, la hora, la IP de la integración y el mensaje completo del error, y envianos esos datos para ubicar el bloqueo en la capa correspondiente.
No apliques permisos 777 ni cambios recursivos a toda la cuenta para resolver un 403. Tampoco desactives el firewall completo: una corrección específica conserva las protecciones y facilita verificar qué resolvió el problema. En hosting compartido, las listas blancas de IP y los ajustes globales del firewall los aplicamos nosotros: pedilo en la consulta con la IP y la hora del bloqueo.
Cómo comprobar que quedó resuelto
La comprobación debe repetir la misma solicitud desde la conexión o el usuario que fallaban, además de verificar el acceso público.
Probá la URL y la acción originales después del ajuste.
Comprobá otra página del sitio y, si corresponde, el acceso al escritorio.
Verificá que las secciones privadas continúen protegidas.
Retirá las excepciones temporales que ya no sean necesarias y registrá el cambio que resolvió el error.
Si el fallo persiste, no acumules cambios de permisos, DNS y seguridad al mismo tiempo. Volvé al último estado conocido y reuní la información del evento.
