Sécurité de Watch-IP et gestion des clés API
Cette page décrit les contrôles d'accès réellement mis en œuvre aujourd'hui dans l'API Watch-IP : le fonctionnement des deux types de clés, l'application des restrictions d'origine, la rotation ou la révocation des clés, et la marche à suivre pour signaler un problème de sécurité. Elle ne revendique aucune certification de conformité ni audit de sécurité indépendant — aucun n'a été réalisé à ce jour.
Deux types de clés, deux contrôles différents
Les clés publiables (utilisées pour GET /v1/geo et POST /v1/email/validate) sont conçues pour s'exécuter dans du code navigateur et ne sont pas secrètes — le contrôle repose sur la liste d'origines autorisées configurée pour la clé, vérifiée par rapport à l'en-tête Origin/Referer de la requête. Les clés secrètes (utilisées pour GET/POST /v1/lookup et POST /v1/risk/check) sont des identifiants serveur à serveur, sans aucune vérification d'origine, puisqu'un appel backend n'a pas d'en-tête Origin de navigateur ; traitez une clé secrète comme un mot de passe de base de données, pas comme un identifiant public. Consultez la page authentification pour le format de requête attendu par chaque type de clé.
Comment la restriction par origine est appliquée
Une requête avec clé publiable provenant d'une origine absente de la liste autorisée pour cette clé reçoit une réponse 403, sans en-tête Access-Control-Allow-Origin. C'est le blocage de cette réponse par le navigateur, avant que le JavaScript de votre page ne puisse la lire, qui constitue l'application réelle du contrôle — le corps JSON de l'erreur est secondaire. La restriction par origine ne rend pas la clé elle-même secrète et n'empêche pas un client non-navigateur d'envoyer un en-tête Origin falsifié ; elle protège spécifiquement la surface des appels effectués depuis un navigateur.
Transport et stockage
Le trafic vers l'API et le tableau de bord est chiffré en transit (TLS/HTTPS) ; l'API n'accepte pas le HTTP en clair pour les requêtes authentifiées par clé. Les clés API sont stockées sous forme hachée (SHA-256), et non en clair, si bien qu'une compromission de la base de données seule n'exposerait pas de valeurs de clé exploitables.
Rotation et révocation
Vous pouvez révoquer ou faire tourner une clé depuis le tableau de bord. La révocation n'est pas instantanée partout : la validité d'une clé est mise en cache jusqu'à 5 minutes après une vérification, si bien qu'une clé révoquée peut continuer à être acceptée pendant jusqu'à 5 minutes après sa révocation — tenez-en compte pour évaluer la rapidité avec laquelle vous pouvez couper l'accès en cas de compromission suspectée, et effectuez une rotation proactive plutôt que de vous fier à la seule révocation pour un incident sensible au facteur temps.
Limitation de débit
Chaque clé est soumise à une limite de débit par compte client sur une fenêtre fixe d'une minute, partagée entre tous les points de terminaison que vous appelez — et non un budget par route. Cela limite les dégâts qu'une clé divulguée ou détournée peut causer sur une courte fenêtre, mais ne remplace pas la rotation d'une clé compromise.
Signaler un problème de sécurité
Écrivez à security@watch-ip.com si vous pensez qu'une clé a été compromise ou si vous avez découvert un problème de sécurité dans l'API ou le tableau de bord. Nous n'avons actuellement ni programme public de bug bounty, ni certification de sécurité tierce — si cela change, cette page l'indiquera avec une date, pas avec un badge.