Skip to main content
Ces bonnes pratiques sont fournies à titre de références exemplaires. Évaluez vos implémentations de manière indépendante.

​
Communication avec les services XBOX

Utilisez l’API XBOX Services (XSAPI) pour les appels aux services XBOX. Elle repose sur les API HTTP et WebSocket de la plateforme, suit toutes les pratiques de sécurité recommandées et est disponible sur plusieurs plateformes. Consultez Prise en main des API XBOX Services.

​
Communication avec les services PlayFab

Utilisez la bibliothèque GDK PlayFab XplatCPP. Elle suit les pratiques de sécurité recommandées, y compris l’authentification, et repose sur les API HTTP et WebSocket de la plateforme. Consultez la bibliothèque GDK PlayFab Azure privée et la documentation du SDK XplatCPP.

​
Communication générale avec les services web

Sur le GDK, utilisez XCurl, libHttpClient ou WinHTTP. Microsoft les teste et les maintient activement.
  • XCurl impose automatiquement une validation complète des certificats SSL.
  • libHttpClient est le plus adapté à la communication WebSocket.
  • Utilisez toujours HTTPS / WSS. Limitez-vous à TLS 1.2 ou 1.3 uniquement.
Consultez la Vue d’ensemble des requêtes web.
Évitez les bibliothèques clientes HTTP ou WebSocket tierces. Le GDK réduit l’accès des API au magasin de certificats système, et le sandboxing des titres le limite davantage. Les consoles restreignent les opérations sur le magasin de certificats à la lecture seule. Les bibliothèques tierces sont intrinsèquement moins sécurisées que les API de la plateforme.

​
Authentification des services web

Authentifiez les services web à l’aide de certificats SSL publics ancrés dans une autorité de certification reconnue par la plateforme. Consultez Microsoft Trusted Root Participants. WinHTTP / XCurl valident automatiquement les certificats. Les certificats auto-signés ou émis par une autorité de certification non prise en charge provoquent des erreurs d’authentification. Pendant le développement, vous pouvez remplacer ou assouplir ces vérifications : ne livrez jamais ces modifications dans les builds de production.

​
Bonnes pratiques pour la pile HTTP

Si votre titre utilise directement WinHTTP ou une autre pile HTTP au lieu de xCurl, configurez explicitement la sécurité : les paramètres par défaut de xCurl ne s’appliquent pas automatiquement ailleurs.

​
Validation des certificats et approbation

  • Validez la chaîne de certificats complète.
  • Validez le nom d’hôte du serveur, et pas seulement l’émetteur.
  • Déterminez si la pile utilise le modèle d’approbation de la plateforme ou un ensemble d’approbation géré séparément.
Le chargement d’un certificat racine de débogage de type Fiddler est une action explicite dans votre pile.

​
Configuration du proxy

  • Découvrez la configuration du proxy système lorsque cela est approprié.
  • Transmettez explicitement les paramètres du proxy à la bibliothèque HTTP.
  • Testez le trafic direct et le trafic via proxy (en particulier pour le débogage local).
Consultez Débogage des piles HTTP personnalisées pour la gestion du proxy XBOX pour les piles non Schannel.

​
Paramètres sécurisés par défaut à examiner

  • Délais d’expiration de connexion et de requête
  • Gestion des redirections
  • Limites de taille des requêtes / réponses
  • Comportement des versions HTTP (y compris les hypothèses sur HTTP/2)
  • Masquage des en-têtes, jetons et URL dans la journalisation et la télémétrie

​
Liste de contrôle recommandée

  • Le trafic de production utilise HTTPS ou WSS.
  • La validation de la chaîne de certificats et du nom d’hôte est activée dans les builds de production.
  • Le modèle d’approbation est défini et documenté.
  • La découverte du proxy / la configuration explicite est prise en charge pour les flux de travail de débogage.
  • Les échecs de certificat, les échecs de proxy et le comportement des délais d’expiration sont délibérément testés (pas seulement le scénario nominal).

​
Authentification du client

Authentifiez les clients GDK à l’aide du jeton d’authentification XSTS. Les services XBOX créent le jeton et fournissent les revendications d’utilisateur, de client et de privilèges. Les clients peuvent utiliser les jetons XSTS pour appeler les services de titre lorsque ceux-ci peuvent être validés de manière sécurisée. Conseils :
  • Configurez les revendications d’authentification XSTS dans Partner Center dans le cadre de la configuration du titre/service.
  • N’envoyez pas directement depuis le client les informations d’utilisateur/client/privilèges (URL ou corps). Validez-les toujours via les revendications XSTS.
  • Les jetons personnalisés de titre/éditeur sont autorisés, mais doivent reposer sur un flux d’authentification XSTS initial. Respectez le format JWT chiffré et l’expiration utilisés par XSTS.
Consultez Authentification des services XBOX et l’exemple GameService pour la validation XSTS.

​
Configuration des algorithmes pour les services web

Limitez TLS aux options robustes uniquement :
  • AES256 ou plus robuste
  • Chiffrements CBC ou GCM
  • SHA256 ou plus robuste
AES256 est accéléré matériellement sur les processeurs modernes. Les autres options présentent des vulnérabilités connues. WinHTTP / XCurl imposent SHA256 (ou supérieur) sur tous les certificats SSL, y compris les certificats auto-signés. Consultez Windows Enforcement of SHA1 Certificates.

​
Génération de certificats SSL

Les certificats racines doivent être :
  • Soit une autorité de certification chaînée à un participant du Microsoft Trusted Root Program. Aucune configuration par titre n’est requise.
  • Soit une autorité de certification Microsoft (y compris les certificats Azure utilisés dans les machines virtuelles et services Azure).
Il existe des options de certificats gratuites et payantes : choisissez celle qui vous convient.

​
Documentation d’API associée

​
Voir aussi

Last modified on October 6, 2026