Security.

Plumb is built to fail closed: tenant reads are scoped by organisation, credentials are hashed or encrypted, outbound targets are checked, and a scan that cannot establish coverage is recorded as failed rather than clean.

Application controls

• Scrypt password hashing with per-password salts; only hashes of sessions, email links, reset links, invitations, recovery codes and API keys are stored.
• Optional two-step verification uses encrypted TOTP seeds, one-time recovery codes, replay protection and a short-lived pending-authentication state that cannot access the product.
• Google ID tokens are signature- and claim-verified server-side and linked by Google’s stable subject identifier, not by a mutable email alone.
• HttpOnly, SameSite cookies; role-based authorisation; server-side admission and plan gates. Account-security changes require recent password or Google reauthentication.
• Origin checks on cookie-authenticated mutations, request-size limits, authentication throttles, and constant-time secret comparison.
• Public-IP validation and redirect refusal for scanner and webhook destinations to reduce server-side request forgery risk.
• Signed customer webhooks and signed, replay-resistant Stripe webhook processing.
• Per-response script nonces in Content Security Policy, HSTS, frame denial, MIME sniffing protection and restricted browser permissions.
• Session controls expose only a user-chosen label and coarse device description; raw IP addresses and user-agent strings are not returned to the browser.

Operational controls

Production runs a single SQLite writer on a persistent infrastructure volume with daily provider snapshots. Jobs are leased, retried with backoff and dead-lettered; stale scans are reconciled; targets pause after three consecutive failures; operators can stop all scanning without deleting queued evidence. Health reporting covers both HTTP and worker progress.

Boundaries

Plumb does not currently claim SOC 2, ISO 27001, formal penetration-test coverage, multi-region failover, or a managed-database recovery objective. Those would require evidence we do not yet hold. Current SQLite architecture is suitable for one-machine operation and must be revisited before horizontal scaling.

Report a vulnerability

Send a concise report to payments@clapdigital.co. Include the affected URL, reproduction steps, impact and a safe contact address. Do not access another customer’s data, degrade the service, or disclose a finding before we have had a reasonable opportunity to investigate.