"Your client does not have permission to get url" : dépanner cette erreur 403 dans vos réseaux informatiques

Quand un poste ou une appli affiche soudain « Your client does not have permission to get url », on sait tout de suite que Google vient de dire non. C’est une erreur 403 bien particulière, celle que le géant affiche quand il comprend la requête mais refuse de la servir. Dans un environnement réseau d’entreprise ou chez un hébergeur, ce message revient régulièrement, que ce soit pendant une recherche Google classique, l’accès à un service interne ou l’appel d’une Cloud Function que vous venez de déployer.

En fait, la plupart du temps ce n’est pas un « vous êtes bloqué pour toujours ». C’est souvent un détail de cache, une IP qui a mauvaise réputation aux yeux de Google, ou tout simplement une permission IAM qui manque sur le projet Cloud. Le truc, c’est de savoir où regarder en premier selon le contexte.

Ce que veut vraiment dire cette erreur

Un 403 classique dit « je sais qui vous êtes, mais vous n’avez pas le droit ». La version Google « Your client does not have permission to get url from this server » ajoute une couche : le serveur a bien reçu la demande, il a vérifié les droits, et il a décidé que le client n’était pas autorisé. Ça arrive sur les services Google eux-mêmes (Scholar, Drive, remotedesktop, etc.) comme sur les applications que vous hébergez chez eux via Cloud Functions ou Cloud Run.

Contrairement à une 401 (pas authentifié du tout), ici le client est souvent déjà connecté. Le refus vient d’une règle de sécurité, d’une réputation d’IP, ou d’une configuration IAM trop stricte par défaut.

Les causes les plus courantes sur un réseau

Du côté utilisateur ou poste client, le cache et les cookies sont coupables dans pas mal de cas. Les données stockées peuvent contenir une vieille session ou un jeton qui ne passe plus. Un VPN ou un proxy qui fait croire à Google que vous êtes dans un pays sous embargo (Cuba est revenu plusieurs fois dans les retours) déclenche aussi le blocage. Et puis il y a l’IPv6 : sur certaines configurations, désactiver temporairement la pile IPv6 règle le problème du jour au lendemain.

Dans les réseaux d’entreprise, un proxy d’inspection ou un filtrage de contenu peut altérer les en-têtes de façon que Google ne reconnaisse plus la requête légitime. Une IP partagée avec d’autres utilisateurs qui ont abusé des API ou du scraping finit parfois sur une liste noire temporaire.

Côté infrastructure et développement, depuis début 2020 Google a changé les règles par défaut sur Cloud Functions et Cloud Run. Les nouvelles fonctions HTTP exigent une authentification. Si vous n’avez pas explicitement accordé le rôle « Cloud Functions Invoker » (ou « Cloud Run Invoker ») à allUsers, tout le monde – y compris vous en navigation directe – reçoit exactement le message « Your client does not have permission to get url ».

Comment diagnostiquer sans perdre une heure

Commencez simple. Ouvrez une fenêtre de navigation privée ou un autre navigateur sur le même poste. Si ça marche, c’est le cache ou une extension. Testez ensuite depuis un autre réseau : partage de connexion mobile, voisin, ou un VPN que vous savez propre. Si l’erreur disparaît sur un autre IP, vous tenez la cause : Google a flagué l’adresse actuelle.

Pour les applis internes ou les endpoints Cloud Functions, regardez les logs du service dans la console Google Cloud. Vous verrez souvent « The caller does not have permission to invoke the function ». C’est le signal clair qu’il manque une liaison IAM.

Et si vous gérez un parc avec des proxies ou des firewalls, capturez une requête avec Wireshark ou tcpdump en sortie du poste problématique. Vous verrez tout de suite si les en-têtes sont modifiés ou si la résolution DNS pointe sur un mauvais endpoint.

Solutions rapides qui marchent dans 80 % des cas

Videz le cache et les cookies du navigateur concerné (ou de tout le profil Chrome si c’est récurrent). Redémarrez le routeur ou le poste – ça force une nouvelle négociation et une IP propre sur certains FAI.

Désactivez le VPN ou le proxy le temps du test. Si vous êtes en entreprise et que le proxy est obligatoire, demandez à l’admin réseau d’ajouter une exception pour les domaines Google concernés ou de vérifier la configuration SSL inspection.

Sur les postes où l’IPv6 pose problème, une commande rapide suffit souvent :

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Ça ne règle pas tout, mais dans les cas documentés où l’erreur était intermittente, ça a permis de retrouver l’accès en quelques secondes.

Le cas spécifique des Cloud Functions et Cloud Run

Si l’erreur apparaît quand vous (ou vos utilisateurs) appelez une fonction que vous avez déployée, la solution est presque toujours du côté IAM.

Dans la console Google Cloud, allez dans Cloud Functions (ou Cloud Run pour les fonctions de deuxième génération). Sélectionnez la fonction, onglet « Permissions » ou « IAM & Admin ». Ajoutez le rôle Cloud Functions Invoker (ou Cloud Run Invoker) au membre allUsers. Validez et attendez une minute que la propagation se fasse.

En ligne de commande, c’est aussi direct :

gcloud functions add-iam-policy-binding NOM_DE_LA_FONCTION \
  --member="allUsers" \
  --role="roles/cloudfunctions.invoker" \
  --project=VOTRE_PROJET

Pour Cloud Run, le rôle équivalent est roles/run.invoker. Une fois accordé, les appels anonymes passent de nouveau.

Attention : si votre organisation a des policies restrictives sur les ressources publiques, vous devrez peut-être passer par Identity-Aware Proxy (IAP) ou restreindre l’accès à des comptes Google Workspace spécifiques. Mais pour la majorité des cas de test ou d’API internes légères, le rôle Invoker sur allUsers suffit.

Astuces pour les administrateurs réseau

Surveillez les journaux Google Cloud et les métriques de vos proxies. Une augmentation soudaine de 403 sur un même préfixe IP ou un même user-agent mérite investigation : soit une campagne de scraping, soit un poste compromis qui agit en proxy malware.

Vérifiez aussi la configuration DNS interne. Une entrée qui pointe vers un ancien load-balancer ou un endpoint décommissionné peut renvoyer des erreurs étranges qui ressemblent à des problèmes de permission.

Enfin, documentez les exceptions VPN et proxy pour les équipes qui travaillent beaucoup avec les services Google. Ça évite les allers-retours inutiles à chaque fois qu’un commercial tombe sur « Your client does not have permission to get url » en déplacement.

Au bout du compte, cette erreur reste l’une des plus simples à diagnostiquer une fois qu’on sait où regarder : cache côté client, réputation IP côté réseau, ou permissions IAM côté infra Cloud. Avec une méthode claire et les bons accès console, on la règle généralement en moins de dix minutes. Et quand c’est réglé, tout le monde retrouve ses services sans même se souvenir du message d’erreur.