Sécurité et confidentialité
Quelles données quittent votre application, ce que Zarex enregistre, et ce qu'il n'enregistre jamais.
Ce que le SDK envoie à Zarex
Pour décider, le SDK envoie, pour chaque requête protégée :
| Donnée | Quand |
|---|---|
| Adresse IP du visiteur | Toujours. |
| Méthode, hôte et chemin (avec les paramètres d'URL) | Toujours. Le Shield y cherche les attaques. |
| Une liste réduite d'en-têtes (User-Agent, Referer…) | Toujours. |
L'en-tête Cookie | Seulement avec inspectCookies: true. |
| Le corps de la requête (48 Ko au plus) | Seulement avec inspectBody: true. |
Vos identifiants (characteristics) | Seulement si vous les fournissez. Ils sont hachés (SHA-256) avant l'envoi : Zarex ne voit jamais la valeur d'origine. |
| E-mail, téléphone, texte | Seulement si vous les fournissez via call, pour les règles de validation et d'analyse. |
Jamais envoyés
Les en-têtes Authorization et Set-Cookie ne sont jamais transmis, quelle que soit votre configuration. La clé API n'est jamais écrite dans les logs du SDK.
Aucune télémétrie
Le SDK ne contacte qu'une seule adresse : le service de décision de Zarex, pour les requêtes que vous protégez. Il n'envoie aucune statistique d'usage ni aucune donnée sur votre application en dehors de ces décisions (la version du SDK est jointe à chaque décision, pour le diagnostic).
Ce que Zarex enregistre dans le journal
Pour chaque décision : le verdict, la règle concernée, l'adresse IP, son pays et son réseau, le User-Agent, la méthode, l'hôte, le chemin sans les paramètres d'URL, quelques en-têtes sans secret (langue, type de contenu, origine…), l'environnement de la clé et le temps passé par Zarex.
Jamais : les cookies, l'en-tête Authorization, le corps des requêtes, la query string, la clé API.
Les décisions sont conservées un an, puis supprimées.
Vos clés et votre compte
- Une clé API n'est affichée qu'une fois, à sa création : Zarex n'en conserve qu'une empreinte et ne peut pas la réafficher.
- Les mots de passe du dashboard sont hachés (bcrypt) : personne, chez Zarex, ne peut les lire.
- La réinitialisation du mot de passe passe par un lien envoyé par e-mail, valable une heure.
Disponibilité : le fail-open
Si Zarex est indisponible, trop lent (500 ms par défaut, réglable avec timeoutMs) ou répond de façon inattendue, la requête de votre visiteur passe. Une panne chez Zarex ne fait jamais tomber votre application. Pendant ce temps, vos requêtes ne sont pas protégées : le SDK l'indique dans vos logs, et la décision est marquée degraded.
Signaler une faille
Vous pensez avoir trouvé une faille de sécurité dans Zarex ? Écrivez à [email protected] en décrivant le problème. Merci de ne pas le rendre public avant que nous l'ayons corrigé.