> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hub2.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sécurité

# 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](https://developer.mozilla.org/fr/docs/Web/HTTP/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](/integration/fr/other_products/payload_signature) 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 :

<Card title="Comportement du WAF" img="https://mintcdn.com/hub2-83/QRWPuZcG9DMHOF_6/assets/HUB2-WAF-HTTP-403-Forbidden.png?fit=max&auto=format&n=QRWPuZcG9DMHOF_6&q=85&s=6da143e2693f14c8d428dc2ed9443bbb" width="633" height="434" data-path="assets/HUB2-WAF-HTTP-403-Forbidden.png">
  Ici, une injection SQL (SQLi attack) est simulée sur l'API HUB2.<br />Le pare-feu web applicatif rejette immédiatement la requête et renvoit une réponse avec le statut `HTTP 403 Forbidden`.
</Card>

<Warning>
  **Remarque :** Le <Tooltip headline="WAF" tip="Web Application Firewall">WAF</Tooltip> renverra *toujours* un corps de réponse au format `text/html`.<br />
  **Veuillez garder cela à l'esprit lors de l'intégration de l'API HUB2.**
</Warning>

### 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é.

<Note>
  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.
</Note>

#### 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 :

<AccordionGroup>
  <Accordion title="Mauvaise pratique" icon="xmark" defaultOpen>
    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. <Icon icon="xmark" iconType="solid" color="#ff1b62" />

    ```http theme={null}
    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. <Icon icon="check" iconType="solid" color="#07c983" />
  </Accordion>

  <Accordion title="Bonne pratique" icon="check">
    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).

    ```http theme={null}
    GET /webhooks/ HTTP/1.1
    Host: api.hub2.io
    Accept: application/json
    User-Agent: Example Merchant backend/1.0

    ```
  </Accordion>
</AccordionGroup>

#### 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 :

<AccordionGroup>
  <Accordion title="Mauvaise pratique" icon="xmark" defaultOpen>
    Remarquez l'**objet JSON sur plusieurs lignes** dans le corps de la requête ci-dessous :

    ```http theme={null}
    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. <Icon icon="check" iconType="solid" color="#07c983" />
  </Accordion>

  <Accordion title="Bonne pratique" icon="check">
    Pour éviter de déclencher la passerelle de sécurité, transformez le contenu multiligne en une **seule ligne de texte**, comme suit :

    ```http theme={null}
    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":{}}
    ```
  </Accordion>
</AccordionGroup>

#### 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 :

<AccordionGroup>
  <Accordion title="Mauvaise pratique" icon="xmark" defaultOpen>
    Remarquez l'en-tête `Content-Type` incorrect par rapport au payload JSON :

    ```http theme={null}
    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. <Icon icon="check" iconType="solid" color="#07c983" />
  </Accordion>

  <Accordion title="Bonne pratique" icon="check">
    Définissez toujours l'en-tête `Content-Type` de manière à **correspondre au format du contenu du corps** :

    ```http theme={null}
    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":{}}
    ```
  </Accordion>
</AccordionGroup>