Sécurité et erreurs - Social media studio

Protéger les clés partenaire

Les clés partenaire autorisent des opérations à l’échelle du projet. Stockez-les dans un gestionnaire de secrets côté serveur ou une variable d’environnement chiffrée, et injectez-les uniquement dans des processus backend de confiance.

N’envoyez jamais une clé partenaire à votre frontend, que ce soit comme configuration, réponse d’API, paramètre de requête ou variable d’environnement rendue. Votre backend doit exposer des endpoints restreints qui autorisent le client connecté avant d’appeler Social media studio.

Utilisez des clés pk_test_ pendant le développement et des clés pk_live_ uniquement en production. Séparez les projets de test et de production, renouvelez régulièrement les clés et révoquez une clé immédiatement si elle a pu être exposée.

Autoriser chaque opération client

Le SDK authentifie votre application, pas le client qui utilise votre produit. Avant chaque appel au SDK :

Authentifiez le client dans votre application.
Retrouvez sur votre serveur le endUserId Social media studio stocké pour ce client.
Vérifiez que les identifiants de connexion et de publication demandés appartiennent à ce client.
Appelez le SDK avec ces identifiants résolus côté serveur.

N’acceptez jamais un endUserId arbitraire venant d’un navigateur pour le transmettre sans vérifier l’appartenance dans votre base de données.

Portées des clés

Les clés partenaire peuvent être restreintes aux capacités dont un service a besoin :

Ressource	Portée de lecture	Portée d’écriture
Utilisateurs finaux	`end_users:read`	`end_users:write`
Connexions	`connections:read`	`connections:write`
Sessions de connexion	`connect_sessions:read`	`connect_sessions:write`
Publications	`posts:read`	`posts:write`
Médias	—	`media:write`
Webhooks	`webhooks:read`	`webhooks:write`

Utilisez si possible des clés distinctes, au moindre privilège, pour les services indépendants.

Gérer les erreurs du SDK

Chaque requête d’API échouée lève une SoMePlatformError :

import {
  SoMePlatformError,
  SoMePlatformClient,
} from "@social-media-scheduler/sdk";

try {
  await soMe.posts.get(endUserId, postId);
} catch (error) {
  if (error instanceof SoMePlatformError) {
    logger.error("Social media studio request failed", {
      status: error.status,
      details: error.details,
    });
  }
  throw error;
}

Statut	Signification	Traitement recommandé
`0`	Erreur réseau, échec DNS ou expiration de la requête	Réessayer avec un délai croissant lorsque c’est sûr
`400`	Entrée invalide, plateforme incompatible ou URL de retour non autorisée	Corriger la requête ; ne pas réessayer telle quelle
`401`	Clé partenaire manquante, invalide, expirée ou révoquée	S’arrêter et renouveler ou remplacer la clé
`403`	La clé n’a pas la portée requise	Utiliser une clé avec les bonnes portées
`404`	La ressource n’existe pas dans ce projet ou pour cet utilisateur final	Réconcilier les identifiants stockés
`409`	L’espace de travail du client n’est pas prêt	Réessayer après avoir résolu l’état signalé
`429`	Limite de débit atteinte	Respecter les indications de nouvelle tentative et utiliser un délai exponentiel
`5xx`	Défaillance temporaire du service Social media studio	Réessayer avec un délai exponentiel plafonné

Pour la création de publications, les nouvelles tentatives ne sont sûres que si vous réutilisez la même clé d’idempotence. Ne relancez pas aveuglément les autres opérations d’écriture, sauf si votre application peut en confirmer le résultat.

Journalisation

Journalisez le contexte de la requête : identifiant de votre client, identifiant de l’utilisateur final, opération, statut HTTP et clé d’idempotence. Ne journalisez pas les clés partenaire complètes, les secrets de webhook, les jetons OAuth, les URL d’import pré-signées ni les métadonnées sensibles des clients.

​Protéger les clés partenaire

​Autoriser chaque opération client

​Portées des clés

​Gérer les erreurs du SDK

​Journalisation

Protéger les clés partenaire

Autoriser chaque opération client

Portées des clés

Gérer les erreurs du SDK

Journalisation