La confiance chez Squish

Squish est une plateforme multi-services. Le site client (squish.co) et le CRM interne (work.squish.co) tournent sur Cloudflare Workers / Pages. Cinq backends Node.js — squish-backend, squish-crm-backend, squish-provisioning, squish-email et squish-hosting — tournent sur Railway dans la région US-East. Les dossiers clients sont hébergés dans Salesforce ; l'état transactionnel, les journaux d'audit et les métadonnées de provisioning résident dans Google Firestore (région US). Les données de paiement sont détenues par Stripe — Squish est hors du périmètre PCI, par conception.

L'enregistrement de domaines passe par NameSilo. L'hébergement mutualisé repose sur des nœuds Plesk hébergés sur des droplets DigitalOcean ; les VPS Managed Cloud utilisent CyberPanel par défaut, sur leur propre droplet. Les sites hébergés sont servis derrière le CDN et le WAF de Bunny. Les licences Microsoft 365 sont fournies via Pax8 (CSP).

• En transit : TLS 1.3 (TLS 1.2 minimum) de bout en bout via Cloudflare. HSTS appliqué sur chaque domaine exposé aux clients.
• Au repos : chiffrement par défaut de Firestore (AES-256), chiffrement de la plateforme Salesforce ; Stripe gère toutes les données de carte avec des contrôles PCI DSS niveau 1.
• Secrets : toutes les clés API, identifiants de comptes de service et chaînes de connexion aux bases de données résident dans les variables d'environnement Railway et les secret bindings Cloudflare — jamais dans le code source.
• Sauvegardes : récupération à un instant donné de Firestore (fenêtre de 7 jours). Les dossiers clients Salesforce résident sur la plateforme Salesforce, avec sa réplication et sa reprise après sinistre intégrées.

• Authentification client : Firebase Auth (e-mail + mot de passe, plus des fournisseurs OAuth optionnels). JWT à courte durée de vie (TTL de 1 heure).
• Authentification du personnel : Cloudflare Access devant chaque surface interne. SSO + MFA obligatoires. Jetons de session limités par application.
• Service à service : clé API interne partagée + contrôles de rôle par route (admin / support / ventes).
• Impersonation : chaque session « agir en tant que client » du personnel est journalisée avec le motif, l'ensemble des actions et les horodatages de début/fin. Les actions destructrices (changement de moyen de paiement, transferts de registrar) sont bloquées pendant l'impersonation par une liste d'exclusion explicite.

Chaque action privilégiée est consignée dans l'une de ces collections Firestore en écriture seule :

• security_events — échecs d'authentification, refus RBAC, tentatives d'IDOR, déclenchements de rate-limit
• impersonation_sessions — sessions du personnel en tant que client, avec sous-collection par action
• billing_actions — émission de remboursements, motifs de plafond par rôle, chaînes de second approbateur
• email_log — chaque e-mail sortant avec son type, le motif de suppression et le statut d'envoi
• webhook_events — verrous d'idempotence des webhooks Stripe / NameSilo / Pax8
• cron_runs — battement de cœur de chaque tâche planifiée (les exécutions manquantes deviennent visibles)

Les contrôles de sécurité ne sont pas seulement décrits sur cette page — les plus critiques sont vérifiés dans le code, afin que le prochain déploiement ne puisse pas les affaiblir en silence.

• Garde-fou CI sur les en-têtes de sécurité des réponses : chaque PR exécute un test de fumée vitest qui fait échouer le build si les en-têtes Content-Security-Policy, Cross-Origin-Resource-Policy, anti-clickjacking ou referrer-policy s'écartent de leurs valeurs attendues.
• Sonde de permissions tierces au démarrage : le backend vérifie au boot que la clé API Stripe configurée dispose de toutes les portées dont dépendent le tableau de bord et les parcours de paiement ; une portée manquante est signalée bruyamment au démarrage plutôt que de se traduire par une panne silencieuse côté client.
• Des helpers SOQL typés rejettent les identifiants malformés au point d'appel au lieu de les convertir silencieusement en une valeur qui élargirait la requête — une défense contre l'injection SOQL côté intégration.
• Manifeste de disponibilité des variables d'environnement : chaque service déclare toutes les variables qu'il consomme, marquées requises ou optionnelles, et un endpoint interne indique celles qui manquent sur l'instance en cours — un secret absent apparaît ainsi lors d'une vérification délibérée après déploiement, et non à la première requête client qui en avait besoin.

Les données opérationnelles sont conservées sur de courtes durées justifiables ; les enregistrements financiers sont gardés pendant les 7 ans exigés par la législation fiscale américaine. Les demandes de suppression des clients sont honorées sous 30 jours pour les données non financières.

Fournisseurs qui traitent des données clients pour notre compte. Chacun opère sous son propre programme de conformité — les liens mènent à leurs pages de confiance publiques.

• Contact sécurité : security@squish.co — l'équipe est alertée en temps réel.
• Politique de divulgation responsable : /.well-known/security.txt
• SLA de première réponse : sous un jour ouvré.
• Notification des clients : sous 72 heures après confirmation d'une violation affectant des données clients, conformément à l'article 33 du RGPD.
• État du système en direct : squish.co/status

Aujourd'hui : Squish opère un programme de sécurité auto-attesté, appuyé sur les contrôles décrits ci-dessus. L'essentiel du référentiel SOC 2 Type 1 (contrôle d'accès, chiffrement, journalisation d'audit, gestion des fournisseurs, gestion des changements) est déjà en place ; l'audit formel est sur la feuille de route.

SOC 2 Type 1 : en cours. Attestation visée dans le courant de l'année.

SOC 2 Type 2 : la période d'observation démarre une fois l'attestation Type 1 obtenue.

Pour les équipes achats : nous remplissons volontiers un questionnaire de sécurité (CAIQ-Lite, SIG-Lite ou votre propre format). Contactez-nous à security@squish.co.

Accord de traitement des données (DPA) : notre DPA standard, aligné sur l'article 28 du RGPD et incluant les clauses contractuelles types de l'UE, est publié sur squish.co/dpa et est intégré automatiquement à nos Conditions d'utilisation.