Configuration du réseau et du WAF

Lorsque vous intégrez l'Universal Commerce Protocol (UCP), les serveurs Google envoient des requêtes HTTP de serveur à serveur à vos points de terminaison d'API et OAuth 2.0. Pour autoriser ce trafic, configurez :

• Votre pare-feu de périmètre
• Votre réseau de diffusion de contenu (CDN)
• Votre pare-feu d'application Web (WAF)
• Votre limiteur de débit
• Vos règles de gestion des bots

Cette configuration évite les blocages de faux positifs lors des paiements des clients, de la découverte de profils et des demandes d'association de comptes en temps réel.

Attention : Google ne relance pas automatiquement les réponses HTTP 403 Forbidden ou 429 Too Many Requests lors des appels de paiement ou d'association de compte. Une seule requête bloquée ou à débit limité entraîne l'échec immédiat de la session de paiement ou d'association de compte du client.

Validation de la requête recommandée

Google achemine les requêtes sortantes de manière dynamique entre les centres de données mondiaux et ne garantit pas de plages d'adresses IP de sortie statiques ni d'adresses IP sources spécifiques à un pays. Pour remplacer les listes d'autorisation d'adresses IP statiques ou le filtrage géographique d'adresses IP, authentifiez le trafic Google entrant au niveau des couches de transport et d'application :

• TLS mutuelle (mTLS) : configurez votre équilibreur de charge de périmètre, votre CDN ou votre passerelle d'API pour valider les certificats client Google signés par les autorités de certification racine UCP de Google (CN=Google UCP Root CA, O=Google LLC pour la production et CN=Google UCP Root CA (stg), O=Google LLC pour la préproduction). Pour obtenir des téléchargements d'autorités de certification racine et des exemples de configuration de passerelle, consultez TLS mutuelle (mTLS) et le guide d'intégration de la sécurité et de mTLS pour les partenaires.
• Identifiants de la couche application : vérifiez l'en-tête OAuth 2.0 Authorization: Bearer <token> ou l'en-tête X-API-Key pour chaque demande de paiement et de commande. Consultez la section Authentification au niveau de la couche application.
• Signatures de requêtes cryptographiques (RFC 9421) : vérifiez les signatures de messages ES256 dans les en-têtes Signature et Signature-Input (et Content-Digest lorsqu'un corps de requête est présent). Vérifiez les signatures par rapport au jeu de clés Web JSON (JWKS) public de Google dans https://ucp.goog/.well-known/ucp.json ou à l'URL multiversion dans l'en-tête UCP-Agent. Récupérez toujours les clés de manière dynamique à partir de l'URL JSON publiée. Pour en savoir plus sur la validation des signatures, consultez la spécification des signatures UCP.

Avertissement : Ne mettez pas en cache le profil UCP-Agent ni ses clés de signature plus longtemps que ce que l'en-tête HTTP Cache-Control autorise (max-age=86400 ou 24 heures). Google effectue régulièrement une rotation des clés de signature, et un cache obsolète rejette les requêtes valides. Lorsqu'une signature de requête utilise un ID de clé inconnu (kid), récupérez à nouveau le profil UCP-Agent avant de rejeter la requête.

Profils de trafic par sous-système

Google utilise des sous-systèmes sortants distincts pour les demandes de paiement et de découverte UCP, et pour les demandes d'association de compte OAuth 2.0. Configurez votre réseau et vos règles WAF pour autoriser tous les profils de trafic applicables dans les sections suivantes.

Avertissement : N'utilisez pas les en-têtes User-Agent ou UCP-Agent seuls pour autoriser le trafic ou contourner les contrôles WAF, de limitation du débit ou de gestion des bots. Les pirates informatiques peuvent usurper les en-têtes HTTP standards. Limitez les exceptions aux points de terminaison UCP et OAuth dédiés qui nécessitent la mTLS, des signatures RFC 9421 ou des identifiants OAuth 2.0 et de clé API. Combinez les vérifications d'en-tête avec les ASN sources validés (AS15169 pour UCP, et AS15169 ou AS396982 associés à l'authentification client OAuth 2.0 pour l'association de comptes).

1. Requêtes API de paiement, de panier et de commande UCP

Les requêtes sortantes vers vos points de terminaison de paiement, de panier et de commande UCP présentent les caractéristiques réseau et HTTP suivantes :

• Numéro de système autonome (ASN) source : AS15169 (Google LLC), publié sur https://www.gstatic.com/ipranges/goog.json.
• En-tête User-Agent : correspond à l'une des valeurs suivantes :
  • Google-Shopping-Merchant-Integration (client sortant par défaut)
  • Google/UCP* (envoyé lorsque la propagation de l'user-agent d'origine est activée)
  • Google-UCP-Prober/1.0 (vérifications d'état périodiques des points de terminaison)
• En-tête UCP-Agent : présent dans les appels de paiement, de panier et de commande UCP au format profile="https://ucp.goog/..." (par exemple, profile="https://ucp.goog/profiles/2026-04-08/ucp.json").
• En-têtes HTTP par méthode :
  • Les requêtes POST et PUT envoient Content-Type: application/json, Request-Id (UUID), Idempotency-Key (UUID), Payment-Environment (live ou sandbox) et Authorization: Bearer <token> (ou X-API-Key). Elles envoient également Content-Digest (sha-256=:...: sur les corps signés RFC 9421) et X-Forwarded-For (lorsqu'une adresse IP d'acheteur d'origine est présente). Les requêtes POST et PUT n'envoient pas d'en-tête Accept. Ne nécessitent pas de Accept: application/json sur les règles de paiement POST ou PUT.
  • GET : les requêtes envoient Accept: application/json, Request-Id (UUID), Payment-Environment (live ou sandbox) et Authorization: Bearer <token> (ou X-API-Key).
• Requêtes de jeton OAuth 2.0 client_credentials : si vous utilisez OAuth 2.0 de machine à machine, Google envoie des requêtes POST avec grant_type=client_credentials depuis AS15169 avec User-Agent: Google-Shopping-Merchant-Integration (Content-Type: application/x-www-form-urlencoded ou application/json). Ces requêtes de jeton n'incluent pas UCP-Agent ni User-Agent: OpenAuth.

Important : Faites correspondre le nom de l'en-tête UCP-Agent sans tenir compte de la casse (UCP-Agent ou Ucp-Agent) et utilisez un caractère générique pour le chemin d'accès au profil (par exemple, profile="https://ucp.goog/*"). Ne codez pas en dur une version de date spécifique dans vos règles WAF. Le codage en dur d'une version de date bloque les futures mises à niveau des spécifications UCP.

2. Découverte du profil UCP (GET /.well-known/ucp)

Google récupère régulièrement votre fiche d'établissement sur GET /.well-known/ucp pour découvrir vos points de terminaison, vos fonctionnalités et vos clés publiques. Consultez Préparer votre profil UCP.

• Numéro de système autonome source : AS15169 (Google LLC)
• En-tête User-Agent : Google-Shopping-Merchant-Integration, Google/UCP* ou Google-UCP-Prober/1.0
• En-têtes HTTP standards : Accept: application/json et Request-Id
• Pas d'en-tête UCP-Agent : les requêtes de découverte de profil n'incluent pas l'en-tête UCP-Agent. Ne nécessite pas UCP-Agent sur GET /.well-known/ucp.

3. Demandes d'association de compte Google (OAuth 2.0)

Si vous acceptez l'association d'identité – OAuth 2.0, l'infrastructure d'association de comptes de Google envoie des requêtes de serveur à serveur à vos points de terminaison de jeton, de révocation et JWKS OAuth 2.0 pour les autorisations authorization_code et refresh_token déléguées par l'utilisateur.

L'association de compte s'exécute sur un pool d'infrastructure Google distinct de celui du paiement UCP :

• Numéros de système autonome sources : AS15169 (Google LLC) et AS396982 (Google Cloud). Étant donné que AS396982 héberge également des charges de travail de clients Google Cloud, associez toujours les règles de numéro de système autonome pour AS396982 à l'authentification du client OAuth 2.0.
• En-tête User-Agent : OpenAuth ou Google-AccountLinking-Fetcher/1.0 (correspond à *OpenAuth* ou Google-AccountLinking-Fetcher*)
• Aucun en-tête UCP : les demandes d'association de compte n'envoient pas l'en-tête UCP-Agent et n'utilisent pas les signatures de message UCP RFC 9421. Ils s'authentifient avec les identifiants client OAuth 2.0 que vous avez configurés.

Checklist pour la gestion des CDN, des WAF et des bots

Les CDN de niveau professionnel (par exemple, Akamai, Cloudflare, Fastly ou AWS CloudFront) évaluent le trafic sur plusieurs modules de sécurité indépendants. Il arrive souvent qu'une liste d'autorisation d'adresses IP ou d'en-têtes dans une règle de pare-feu réseau n'exempte pas la requête des limiteurs de débit en aval ou des tests de gestion des bots.

Vérifiez que votre configuration CDN et WAF répond aux quatre exigences de la liste suivante :

1. Exempte du blocage géographique des adresses IP (pare-feu géographique) : ne bloquez pas les adresses IP sources non nationales sur vos chemins d'API UCP, /.well-known/ucp ou vos points de terminaison OAuth 2.0. Google achemine les requêtes UCP et d'association de comptes depuis des centres de données mondiaux (AS15169 et AS396982). Les adresses IP sources sont souvent résolues dans des pays situés en dehors de votre marché principal.
2. Exempte de limites de débit par adresse IP du client (contrôles de débit) : les règles de limitation du débit du client plafonnent généralement les requêtes par adresse IP du client (par exemple, 15 à 20 requêtes par seconde et par adresse IP). Google multiplexe les requêtes de nombreux acheteurs simultanés sur un petit nombre d'adresses IP NAT sortantes partagées. Les limiteurs de débit par adresse IP déclenchent des blocages HTTP 429 ou 403 à mesure que le trafic augmente. Exemptez le trafic de l'association de comptes et de l'UCP Google des limites de débit par adresse IP. Vous pouvez également appliquer des limites de débit par jeton utilisateur ou par session de paiement.
3. Exempte des tests de détection de bots basés sur le navigateur (gestion des bots) : les modules de gestion des bots (par exemple, Akamai Bot Manager ou Cloudflare Bot Management) appliquent fréquemment des vérifications du navigateur sur les points de terminaison de paiement et de connexion. Configurez une exception de gestion des bots pour vos chemins d'API UCP, /.well-known/ucp et les points de terminaison OAuth /token. N'exigez pas les vérifications de navigateur suivantes sur ces points de terminaison :
   • Tests JavaScript ou CAPTCHA dans le navigateur
   • Cookies de télémétrie du navigateur (par exemple, Akamai _abck ou bm_sz)
   • Correspondance d'empreinte TLS/JA3/JA4 du navigateur
4. N'utilisez pas les listes d'adresses IP des robots d'exploration Google pour la liste d'autorisation UCP : n'utilisez pas les fichiers de plages d'adresses IP des robots d'exploration ou des récupérateurs Google pour vos listes d'autorisation de pare-feu UCP ou d'association de comptes. Cette restriction s'applique à googlebot.json, common-crawlers.json, special-crawlers.json, user-triggered-fetchers.json et user-triggered-fetchers-google.json (voir Vérifier les requêtes de Google). Ces listes d'adresses IP couvrent les robots d'exploration Web et de recherche, et non l'intégralité du pool sortant utilisé par l'UCP et l'association de comptes Google.