403 Forbidden

Utilisation

Lorsqu’une erreur 403 Forbidden arrive, le client ne dispose pas de permissions suffisantes pour accéder à la ressource. Il s’agit d’une erreur courante et générale indiquant au client que la requête n’est pas autorisée. Ce statut diffère de 401 Unauthorized, car l’erreur persiste même après que le client se réauthentifie et soumet à nouveau la requête. Le statut plus spécifique 405 Method Not Allowed indique que la ressource est disponible mais que la méthode HTTP employée n’est pas permise.

403 contre 404, un choix de sécurité

Les serveurs renvoient intentionnellement 404 au lieu de 403 pour masquer le fait qu’une ressource existe. Répondre 403 confirme que la ressource est présente mais à accès restreint, ce qui n’est pas souhaitable pour des chemins sensibles. Le choix entre 403 et 404 est une décision délibérée de conception de la sécurité.

Impact SEO

Les moteurs de recherche comme Google n’indexent pas une URL qui renvoie un statut 403. Les URL précédemment indexées qui renvoient ce code de statut sont retirées des résultats de recherche. Les pages renvoyant ce code ne gaspillent pas de budget d’exploration. N’utilisez pas 403 pour ralentir Googlebot. Seul 429 réduit la fréquence d’exploration.

Exemple

Le client demande une ressource protégée et le serveur répond 403 Forbidden pour indiquer que le client n’a pas accès. Le corps de la réponse explique la restriction.

Requête

GET /tech-news/confidential.pdf HTTP/1.1
Host: example.com

Réponse

HTTP/1.1 403 Forbidden
Content-Type: text/html
Content-Length: 154

<html>
  <head>
    <title>Access Denied</title>
  </head>
  <body>
    <p>Permission to access this resource is
    restricted.</p>
  </body>
</html>

Comment corriger

Un 403 Forbidden signifie que le serveur a compris la requête mais refuse d’autoriser l’action.

Vérifiez les permissions des fichiers et des répertoires sur le serveur. Sous Linux, contrôlez la propriété et les bits de permission avec ls -la. Le processus du serveur web (s’exécutant généralement en tant que www-data ou nginx) a besoin d’un accès en lecture au fichier demandé. Permissions standard : 755 pour les répertoires, 644 pour les fichiers. Correction récursive :

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html

nginx exige en outre la permission d’exécution sur chacun des répertoires parents du chemin menant de / au fichier servi.

Recherchez des règles de refus dans .htaccess ou dans la configuration du serveur. Les directives Require d’Apache, les règles deny de nginx ou des contrôles d’accès similaires bloquent certains chemins ou plages d’IP. Dans Apache, cherchez Require all denied ou Deny from all dans .htaccess ou dans les blocs . Dans nginx, cherchez deny all; à l’intérieur des blocs location. Examinez les fichiers de configuration concernés et consultez le journal d’erreurs pour connaître le motif précis du refus.

Confirmez que l’IP à l’origine de la requête n’est pas bloquée. Un pare-feu, un pare-feu applicatif web (WAF) ou une règle de blocage géographique rejette les requêtes provenant d’adresses restreintes. Consultez les journaux d’accès du serveur à la recherche d’entrées de refus. Cloudflare, AWS WAF et mod_security produisent tous des réponses 403 lorsque des règles se déclenchent. Examinez le tableau de bord du WAF ou le journal d’audit pour identifier la règle bloquante.

Assurez-vous que l’utilisateur authentifié possède le rôle ou la portée requis. Même avec une authentification valide, le compte doit disposer du bon niveau de permission. Vérifiez l’attribution des rôles dans le système de contrôle d’accès de l’application. Les points de terminaison d’API renvoient fréquemment 403 lorsque le jeton ne dispose pas des portées OAuth requises.

Vérifiez les réglages d’index de répertoire lors de la demande d’un dossier. Demander un répertoire dépourvu de fichier d’index par défaut (par exemple index.html) renvoie 403 lorsque le listage de répertoire est désactivé. Ajoutez un fichier d’index ou activez le listage. Dans nginx :

location /files/ {
    autoindex on;
}

Dans Apache, ajoutez Options +Indexes à la configuration du répertoire. Activer le listage de répertoire sur des serveurs de production présente un risque de sécurité.

Vérifiez les politiques SELinux ou AppArmor. Sur les systèmes RHEL/CentOS, SELinux refuse au serveur web l’accès aux fichiers situés hors des chemins attendus, même lorsque les permissions Unix autorisent la lecture. Lancez sestatus pour connaître le mode SELinux et examinez /var/log/audit/audit.log à la recherche d’entrées refusées. Réétiquetez les fichiers avec restorecon -Rv /var/www/html ou définissez le bon contexte avec chcon.

Examinez les exigences de certificat client SSL/TLS. Les serveurs configurés pour le TLS mutuel renvoient 403 lorsque le client ne présente pas de certificat valide. Vérifiez la directive ssl_verify_client de nginx ou la directive SSLVerifyClient d’Apache.

Références de code

.NET

HttpStatusCode.Forbidden

Rust

http::StatusCode::FORBIDDEN

Rails

:forbidden

http.StatusForbidden

Symfony

Response::HTTP_FORBIDDEN

Python3.5+

http.HTTPStatus.FORBIDDEN

Java

java.net.HttpURLConnection.HTTP_FORBIDDEN

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_FORBIDDEN

Angular

@angular/common/http/HttpStatusCode.Forbidden