Vertrouwen bij Squish

Squish is een platform met meerdere services. De klantgerichte site (squish.co) en het interne CRM (work.squish.co) draaien op Cloudflare Workers / Pages. Vijf Node.js-backends — squish-backend, squish-crm-backend, squish-provisioning, squish-email en squish-hosting — draaien op Railway in de regio US-East. Klantrecords staan in Salesforce; transactionele status, auditlogs en provisioning-metadata staan in Google Firestore (regio VS). Betaalgegevens worden beheerd door Stripe — Squish valt by design buiten de PCI-scope.

Domeinregistratie loopt via NameSilo. Gedeelde webhosting draait op Plesk-nodes op DigitalOcean-droplets; Managed Cloud-VPS'en gebruiken standaard CyberPanel op een eigen droplet. Gehoste sites gaan achter de CDN en WAF van Bunny langs. Microsoft 365-licenties lopen via Pax8 (CSP).

• Onderweg: TLS 1.3 (minimaal TLS 1.2) end-to-end via Cloudflare. HSTS afgedwongen op elk klantgericht domein.
• In rust: standaardversleuteling van Firestore (AES-256), Salesforce-platformversleuteling; Stripe verwerkt alle kaartgegevens met PCI DSS Level 1-controles.
• Secrets: alle API-sleutels, serviceaccount-credentials en databaseverbindingsstrings staan in Railway-omgevingsvariabelen en Cloudflare secret bindings — nooit in de broncode.
• Back-ups: Firestore point-in-time recovery (venster van 7 dagen). Klantrecords in Salesforce draaien op het Salesforce-platform met ingebouwde replicatie en disaster recovery.

• Klantauthenticatie: Firebase Auth (e-mail + wachtwoord, plus optionele OAuth-providers). Kortlevende JWT's (TTL van 1 uur).
• Medewerkersauthenticatie: Cloudflare Access vóór elk intern systeem. SSO + MFA verplicht. Sessietokens per app gescopeerd.
• Service-naar-service: gedeelde interne API-sleutel + rolcontroles per route (admin / support / sales).
• Impersonatie: elke "handel als klant"-sessie van een medewerker wordt gelogd met reden, alle uitgevoerde acties en start-/stoptijdstempels. Destructieve acties (wijzigen van betaalmethoden, registrar-overdrachten) worden tijdens impersonatie geblokkeerd via een expliciete denylist.

Elke bevoorrechte actie komt terecht in een van deze append-only Firestore-collecties:

• security_events — mislukte aanmeldingen, RBAC-weigeringen, IDOR-pogingen, rate-limit-overschrijdingen
• impersonation_sessions — medewerker-als-klant-sessies met sub-collectie per actie
• billing_actions — uitgegeven terugbetalingen, redenen voor rollimieten, tweede-goedkeurderketens
• email_log — elke uitgaande e-mail met type, onderdrukkingsreden en verzendstatus
• webhook_events — idempotentie-leases voor Stripe- / NameSilo- / Pax8-webhooks
• cron_runs — heartbeat voor elke geplande taak (zodat gemiste runs zichtbaar zijn)

Beveiligingscontroles staan niet alleen op deze pagina beschreven — de dragende controles zijn in code vastgelegd, zodat een volgende deploy ze niet ongemerkt kan verzwakken.

• CI-gate op beveiligingsheaders van responses: elke PR draait een vitest-smoketest die de build laat falen als Content-Security-Policy, Cross-Origin-Resource-Policy, anti-clickjacking- of referrer-policy-headers afwijken van hun bedoelde waarden.
• Permissiecheck van derden bij het opstarten: de backend controleert bij het starten of de geconfigureerde Stripe-API-sleutel elke scope heeft waarvan het dashboard en de checkoutflows afhankelijk zijn; een ontbrekende scope wordt luid gelogd bij het opstarten in plaats van als stille klantgerichte fout op te duiken.
• Type-gedreven SOQL-helpers weigeren misvormde identifiers op de aanroepplek in plaats van ze stilzwijgend om te zetten naar een waarde die de query zou verbreden — bescherming tegen SOQL-injectie aan de integratiekant.
• Gereedheidsmanifest voor omgevingsvariabelen: elke service declareert alle variabelen die hij gebruikt, gemarkeerd als vereist of optioneel, en een intern endpoint meldt welke ontbreken op de draaiende instantie — zo komt een ontbrekend secret aan het licht bij een bewuste controle na de deploy in plaats van bij het eerste klantverzoek dat het nodig had.

Operationele gegevens worden slechts kort en verdedigbaar bewaard; financiële gegevens worden bewaard gedurende de 7 jaar die de Amerikaanse belastingwetgeving vereist. Verwijderverzoeken van klanten worden voor niet-financiële gegevens binnen 30 dagen uitgevoerd.

Leveranciers die namens ons klantgegevens verwerken. Elk werkt onder een eigen complianceprogramma — links verwijzen naar hun openbare trust-pagina's.

• Beveiligingscontact: security@squish.co — medewerkers worden realtime gewaarschuwd.
• Responsible-disclosurebeleid: /.well-known/security.txt
• SLA voor eerste reactie: binnen één werkdag.
• Klantmelding: binnen 72 uur na een bevestigd datalek dat klantgegevens raakt, conform artikel 33 van de AVG.
• Live systeemstatus: squish.co/status

Vandaag: Squish voert een zelf-geattesteerd beveiligingsprogramma, gedragen door de hierboven beschreven controles. Het grootste deel van de SOC 2 Type 1-controleset (toegangsbeheer, versleuteling, audit-logging, leveranciersbeheer, wijzigingsbeheer) is al operationeel; een formele audit staat op de roadmap.

SOC 2 Type 1: in uitvoering. Attestatie beoogd voor later dit jaar.

SOC 2 Type 2: de observatieperiode start zodra de Type 1-attestatie binnen is.

Voor inkoopteams: we vullen graag een beveiligingsvragenlijst in (CAIQ-Lite, SIG-Lite of uw eigen format). Neem contact op via security@squish.co.

Verwerkersovereenkomst (DPA): onze standaard-DPA, afgestemd op artikel 28 van de AVG en inclusief de EU Standard Contractual Clauses, is gepubliceerd op squish.co/dpa en maakt automatisch deel uit van onze Servicevoorwaarden.