Skip to main content

​
Considérations de sécurité

La sécurité demeure la priorité absolue dans le domaine des transactions financières en ligne.

​
Intégration

Pour garantir que les échanges entre le marchand et HUB2 restent confidentiels, et que seul le marchand est à l’origine des transactions (et donc du montant et des autres propriétés de celles-ci), l’intégration de l’API ne doit se faire que du côté serveur. Les données sensibles, telles que les clés API, ne doivent jamais être divulguées, que ce soit sur un site web ou dans une application mobile. Cette approche renforce la sécurité en évitant l’exposition directe des clés API et des informations sensibles du côté client. En effectuant les transactions du côté serveur, les risques d’attaques malveillantes, telles que les manipulations de données côté client, sont considérablement réduits.

​
CORS

Pour se prémunir des éventuelles intégrations côté client, l’API HUB2 est paramétrée pour ne jamais pouvoir être chargée depuis le navigateur du client final. En d’autres termes, les en-têtes HTTP concernant le partage des ressources entre origines multiples (CORS) ont été correctement paramétrées.

​
Signature

Afin d’améliorer la sécurité et l’intégrité des interactions avec l’API, un mécanisme optionnel de signature de la charge utile est disponible. Cette fonctionnalité permet aux marchands de signer cryptographiquement le corps de la requête JSON envoyé à l’API. En vérifiant cette signature, il est possible de s’assurer que les données n’ont pas été altérées pendant le transfert et qu’elles proviennent d’une source de confiance. Cette couche de sécurité supplémentaire est particulièrement utile pour les transactions financières sensibles. Consultez la page d’intégration pour comprendre comment le mettre en place.

​
Mécanismes de sécurité de la plateforme

Afin de protéger la plateforme HUB2, plusieurs composants de sécurité sont mis en œuvre à différents niveaux de l’infrastructure. Au niveau du périmètre, un Web Application Firewall (WAF) analyse chaque requête HTTP avant de la transmettre au backend. Son rôle principal est de détecter et de bloquer les requêtes HTTP malveillantes avant qu’elles n’atteignent la couche applicative. Pour les requêtes rejetées, les clients seront confrontés au comportement suivant :
HUB2-WAF-HTTP-403-Forbidden

Comportement du WAF

Ici, une injection SQL (SQLi attack) est simulée sur l’API HUB2.
Le pare-feu web applicatif rejette immédiatement la requête et renvoit une réponse avec le statut HTTP 403 Forbidden.
Remarque : Le renverra toujours un corps de réponse au format text/html.
Veuillez garder cela à l’esprit lors de l’intégration de l’API HUB2.

​
Résolution des erreurs HTTP 403 Forbidden courantes

Si une requête légitime rencontre une erreur HTTP 403 Forbidden, veuillez d’abord suivre les directives ci-dessous pour vous assurer que votre intégration est conforme à nos standards de sécurité.
Si votre requête est toujours rejetée après l’application des directives ci-dessous, n’hésitez pas à ouvrir un ticket auprès de l’équipe de support HUB2.

​
1. Requête HTTP GET contenant un corps (Body)

  • Les requêtes GET ne doivent PAS inclure de contenu dans le corps (Body). Toutes les requêtes non conformes seront rejetées par la passerelle de sécurité HUB2.
  • L’en-tête Content-Length n’est pas obligatoire pour une requête GET. Cependant, s’il est inclus, il doit être défini sur 0 et le corps de la requête (Body) doit rester complètement vide.
Par exemple :

Mauvaise pratique

Remarquez les en-têtes Content-Type et Content-Length envoyés, ainsi que la présence d’un corps (Body) non-vide pour une requête GET.De telles requêtes seront rejetées. 
GET /webhooks/ HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0
Content-Type: application/json <------------ Ici
Content-Length: 184 <----------------------- Ici

{"url":"https://my.webhook.target","events":["payment.created","payment_intent.created"],"description":"This is a webhook trigger upon payment & payment_intent creation","metadata":{}}
^----------- Ici
Consultez la Bonne pratique ci-dessous pour corriger cela.
Appliquez les recommandations suivantes pour éviter de déclencher la passerelle de sécurité :
  1. Supprimez entièrement le contenu du corps de la requête.
  2. Supprimez les en-têtes Content-Type et Content-Length (Content-Length est généralement calculé automatiquement par votre bibliothèque cliente HTTP, il n’y a donc généralement rien de plus à configurer).
GET /webhooks/ HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0

​
2. Contenu JSON multi-ligne (non-stringified)

Toutes les requêtes HTTP POST utilisant application/json doivent être linéarisées (stringified), c’est à dire formattées sur une seule ligne de texte. Les payloads JSON formattés sur plusieurs lignes seront rejetés par la passerelle de sécurité HUB2. La présence de retours à la ligne (CR/LF) ou d’espaces (sauf à l’intérieur des valeurs elles-mêmes) dans la chaîne JSON peut déclencher les règles de filtrage. Par exemple :

Mauvaise pratique

Remarquez l’objet JSON sur plusieurs lignes dans le corps de la requête ci-dessous :
POST /webhooks/ HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0
Content-Type: application/json
Content-Length: 214

v----------- Ici
{
    "url": "https://my.webhook.target",
    "events": [
        "payment.created",
        "payment_intent.created"
    ],
    "description": "This is a webhook trigger upon payment & payment_intent creation",
    "metadata": {}
}
Consultez la Bonne pratique ci-dessous pour corriger cela.
Pour éviter de déclencher la passerelle de sécurité, transformez le contenu multiligne en une seule ligne de texte, comme suit :
POST /webhooks/ HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0
Content-Type: application/json
Content-Length: 184

{"url":"https://my.webhook.target","events":["payment.created","payment_intent.created"],"description":"This is a webhook trigger upon payment & payment_intent creation","metadata":{}}

​
3. Le contenu du corps diffère de l’en-tête Content-Type

L’API HUB2 n’accepte actuellement que des payloads au format JSON. Si une requête HTTP est envoyée avec un contenu JSON valide, mais que l’en-tête Content-Type est défini sur une valeur différente (par exemple, text/plain, text/xml ou application/x-www-form-urlencoded), la passerelle de sécurité l’analysera de manière incorrecte et bloquera la requête. Par exemple :

Mauvaise pratique

Remarquez l’en-tête Content-Type incorrect par rapport au payload JSON :
POST /webhooks/ HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0
Content-Type: application/x-www-form-urlencoded <------------ Ici
Content-Length: 184

{"url":"https://my.webhook.target","events":["payment.created","payment_intent.created"],"description":"This is a webhook trigger upon payment & payment_intent creation","metadata":{}}
Consultez la Bonne pratique ci-dessous pour corriger cela.
Définissez toujours l’en-tête Content-Type de manière à correspondre au format du contenu du corps :
POST /webhooks/ HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0
Content-Type: application/json <------------ Ici
Content-Length: 184

{"url":"https://my.webhook.target","events":["payment.created","payment_intent.created"],"description":"This is a webhook trigger upon payment & payment_intent creation","metadata":{}}