Analytics House

Architecture de sécurité

Analytics House s’exécute dans des bacs à sable V8 isolés de Cloudflare Workers, avec des requêtes Cloudflare D1 SQLite paramétrées, une isolation stricte des locataires et une vérification de sécurité automatisée de bout en bout.

1. Authentification et renforcement des identifiants

  • Hachage des mots de passe : les mots de passe sont hachés avec PBKDF2-SHA256 (WebCrypto), 100 000 itérations et un sel aléatoire unique de 128 bits par utilisateur. La vérification utilise une comparaison d’octets à temps constant pour empêcher les attaques temporelles par canal auxiliaire.
  • Jetons de session et de réinitialisation : les sessions utilisent des JWT HS256 signés, valables 7 jours. Les liens de réinitialisation du mot de passe utilisent des jetons aléatoires à usage unique, stockés uniquement sous forme d’empreintes SHA-256 qui expirent au bout d’une heure.
  • Limitation de débit en périphérie : les tentatives de connexion, les inscriptions, les réinitialisations de mot de passe, l’ingestion d’événements (par projet et par IP/relais), les envois de rapports de test et les points de terminaison de l’API sont protégés par des limiteurs à fenêtre glissante qui renvoient 429 Too Many Requests avec des en-têtes Retry-After.

2. Isolation multilocataire et contrôle d’accès basé sur les rôles (RBAC)

  • Cloisonnement strict des locataires : chaque requête SQL lie project_id et vérifie l’appartenance au projet avant exécution. Les requêtes non autorisées reçoivent 404 Not Found, de sorte que les identifiants de projet ne peuvent pas être énumérés.
  • Rôles propriétaire, administrateur et lecteur : les lecteurs ont un accès en lecture seule aux tableaux de bord agrégés ; les exports d’événements bruts leur sont bloqués (403) et les flux d’événements bruts masquent automatiquement user_id, session_id, visitor_id et city pour les lecteurs.
  • Clés d’API de statistiques en lecture seule à portée limitée (ea_sk_...) : seuls l’empreinte SHA-256 et le préfixe de 12 caractères sont stockés dans D1. Les clés de statistiques ne peuvent jamais lire les événements bruts, gérer les paramètres ni révéler la clé d’API d’ingestion.

3. Sécurité de la chaîne d’approvisionnement et des webhooks

  • Subresource Integrity (SRI) : le panneau Confidentialité et paramètres de chaque projet calcule l’empreinte d’intégrité sha384-... actuelle de /tracker.js, afin que les sites puissent épingler les octets exacts du script dans leur balise HTML <script integrity="...">.
  • Webhooks d’alerte renforcés contre les SSRF : les webhooks d’alerte sortants (Slack, Discord et personnalisés) n’acceptent que https:// et bloquent localhost, les adresses de bouclage, les adresses link-local et les plages d’adresses IP privées RFC 1918.
  • Protection contre l’injection CSV : tous les exports CSV neutralisent les cellules commençant par un caractère déclencheur de formule (=, +, -, @, tabulation, CR).
  • En-têtes de sécurité HTTP : les réponses imposent X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin et une liste stricte d’origines CORS autorisées.

4. Surveillance de la disponibilité et divulgation responsable

Des vérifications de l’état de la base de données et du Worker s’exécutent toutes les 15 minutes et sont publiées sur la page publique État du service. Pour signaler une vulnérabilité de sécurité, écrivez à contact@analytics.house ou contactez-nous via Contact et support.