Considérations de sécurité

La sécurité est essentielle pour les transactions financières en ligne.

Intégration

Pour garantir la confidentialité des échanges entre le marchand et HUB2, et que seul le marchand est à l’origine des transactions (et donc de leur montant et de leurs autres propriétés), l’API doit être intégrée uniquement côté serveur. Les données sensibles, telles que les clés API, ne doivent jamais être exposées, que ce soit sur un site web ou dans une application mobile. Ne pas exposer les clés API et les informations sensibles côté client, et effectuer les transactions côté serveur, réduit considérablement les risques d’attaques telles que la manipulation de données côté client.

CORS

Pour empêcher les intégrations côté client, l’API HUB2 ne peut pas être appelée depuis le navigateur du client final. L’API ne renvoie pas d’en-têtes de partage des ressources entre origines multiples (CORS) : les navigateurs bloquent donc les requêtes cross-origin vers l’API.

Signature

Un mécanisme optionnel de signature de la charge utile renforce la sécurité et l’intégrité des échanges avec l’API. Il permet aux marchands de signer cryptographiquement le corps JSON de la requête envoyée à l’API. La vérification de cette signature garantit que les données n’ont pas été altérées pendant le transfert et qu’elles proviennent d’une source de confiance. Consultez la page d’intégration pour savoir comment le mettre en place.

Mécanismes de sécurité de la plateforme

Plusieurs composants de sécurité protègent la plateforme HUB2 à différents niveaux. Au niveau du périmètre, un Web Application Firewall (WAF) analyse chaque requête HTTP avant de la transmettre. Son rôle est de détecter et de bloquer les requêtes HTTP malveillantes avant qu’elles n’atteignent l’application. Les requêtes rejetées reçoivent la réponse suivante :

Comportement du WAF

Ici, une attaque par injection SQL (SQLi) est simulée sur l’API HUB2.
Le pare-feu applicatif web rejette immédiatement la requête et renvoie une réponse avec le statut HTTP 403 Forbidden.

Remarque : le renvoie toujours un corps de réponse au format text/html.
Tenez-en compte lors de l’intégration de l’API HUB2.

Résolution des erreurs `HTTP 403 Forbidden` courantes

Si une requête légitime reçoit une réponse HTTP 403 Forbidden, vérifiez d’abord que votre intégration respecte les règles ci-dessous.

Si votre requête est toujours rejetée après application de ces règles, contactez le support HUB2.

1. Requête HTTP `GET` contenant un corps

Les requêtes GET ne doivent PAS contenir de corps. La passerelle de sécurité HUB2 rejette toutes les requêtes non conformes.
L’en-tête Content-Length n’est pas obligatoire pour une requête GET. S’il est présent, il doit valoir 0 et le corps doit être vide.

Par exemple :

Mauvaise pratique

Remarquez les en-têtes Content-Type et Content-Length, ainsi que le corps non vide, envoyés avec une requête GET.De telles requêtes sont 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.

Bonne pratique

Pour éviter de déclencher la passerelle de sécurité :

Supprimez entièrement le corps de la requête.
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 en général rien à configurer).

GET /webhooks HTTP/1.1
Host: api.hub2.io
Accept: application/json
User-Agent: Example Merchant backend/1.0

2. Contenu JSON sur plusieurs lignes (non linéarisé)

Toutes les requêtes HTTP POST utilisant application/json doivent envoyer le JSON linéarisé (stringified), c’est-à-dire sur une seule ligne de texte. La passerelle de sécurité HUB2 rejette les payloads JSON formatés sur plusieurs lignes : des retours à la ligne (CR/LF) ou des espaces en dehors des valeurs elles-mêmes peuvent 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: 232

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.

Bonne pratique

Pour éviter de déclencher la passerelle de sécurité, envoyez le corps sur une seule ligne de texte :

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. Corps ne correspondant pas à l’en-tête `Content-Type`

L’API HUB2 n’accepte que des payloads au format JSON. Si une requête envoie un JSON valide mais que l’en-tête Content-Type a une autre valeur (par exemple text/plain, text/xml ou application/x-www-form-urlencoded), la passerelle de sécurité l’analyse de manière incorrecte et bloque 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.

Bonne pratique

Définissez toujours l’en-tête Content-Type de manière à correspondre au format 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":{}}

Guide de démarrage

Transferts

Paiements

Webhooks

Processing Only

Payment Links

Sous-marchands

Autre

Sécurité

Considérations de sécurité

Intégration

CORS

Signature

Mécanismes de sécurité de la plateforme

Comportement du WAF

Résolution des erreurs `HTTP 403 Forbidden` courantes

1. Requête HTTP `GET` contenant un corps

2. Contenu JSON sur plusieurs lignes (non linéarisé)

3. Corps ne correspondant pas à l’en-tête `Content-Type`

​Considérations de sécurité

​Intégration

​CORS

​Signature

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

Comportement du WAF

​Résolution des erreurs HTTP 403 Forbidden courantes

​1. Requête HTTP GET contenant un corps

​2. Contenu JSON sur plusieurs lignes (non linéarisé)

​3. Corps ne correspondant pas à l’en-tête Content-Type

Considérations de sécurité

Intégration

CORS

Signature

Mécanismes de sécurité de la plateforme

Résolution des erreurs `HTTP 403 Forbidden` courantes

1. Requête HTTP `GET` contenant un corps

2. Contenu JSON sur plusieurs lignes (non linéarisé)

3. Corps ne correspondant pas à l’en-tête `Content-Type`