Security

Accounts and sessions

• Passphrases are hashed with bcrypt at cost 12. The plaintext is never written to disk and cannot be recovered. A forgotten passphrase is reset.
• A minimum length of 10 characters is enforced, and phrases are encouraged over short scrambles.
• A failed sign-in still performs a bcrypt comparison against a decoy hash, so response timing does not reveal whether an email address has an account.
• Sessions are server-side: the browser holds only a 32-byte random identifier, with no claims inside it. We can revoke any session immediately, and there is no signed token that stays valid after revocation.
• The session cookie is httpOnly, sameSite=lax, and secure in production. It expires after 30 days, and expired rows are purged automatically.
• Each session records the IP address and user-agent it was created from, so you can review and revoke your own active sessions.
• Sign-in and sign-up are rate-limited separately and more tightly than the rest of the API.
• Security-relevant events (sign-in, failed sign-in, passphrase change, invitation, firm deletion) are written to an audit log with the acting account and IP.
• API keys are shown once at creation and stored only as hashes. Webhook endpoints must be HTTPS and carry a signing secret.

Keeping firms apart

Every firm-scoped query filters on the organisation derived from the server-side session. A value supplied by the client is never used. Role gates (owner, admin, member) sit on top of that and guard actions, while the organisation filter guards visibility. The two are separate on purpose: a role check alone would be one missing line away from exposing another firm's board.

The automated test suite includes cases that assert a member cannot reach firm-level settings and that an export contains that firm's data and nobody else's.

Application hardening

• A Content Security Policy restricts script, style, font, image and connection sources; framing is denied outright.
• All API traffic is rate-limited; the live collaboration stream is excluded from the per-minute quota so it is not severed mid-connection.
• Request bodies are validated against explicit schemas before reaching any handler.
• All SQL is parameterised through prepared statements. Multi-statement invariants run inside transactions so a mid-write failure cannot leave a torn record.
• Solicitation content is treated as untrusted input, since it comes from third-party feeds. The browser test suite includes a case that renders a deliberately hostile solicitation title and model response and asserts they stay inert.
• Sessions and invitations use cryptographically random identifiers. Invitation tokens are stored only as SHA-256 hashes, so a database disclosure does not hand anyone working invitation links.

Where data lives

The application and its database run on infrastructure operated by Render in the United States. Traffic is served over HTTPS/TLS.

The database is a SQLite file on a persistent disk attached to the web service. Encryption at rest is provided by our hosting provider's storage. Purceivo does not add its own at the application layer, and we say so plainly instead of implying a cryptographic control we did not build. We do not currently offer customer-managed encryption keys.

A scheduled maintenance job reclaims space and checkpoints the write-ahead log monthly. Backups are as provided by the hosting platform; a documented, independently tested restore procedure is on the list in section 07 and is not yet in place.

Change management

Schema changes are numbered, transactional and idempotent migrations, applied in order on boot and recorded in the database. A half-applied migration fails the boot, so the schema is never left in an indeterminate state.

Every push and pull request runs two automated suites in CI: an API and job suite, and a browser suite that exercises the click-through a real user performs. Both must pass before a change ships. Tests are written against defects that actually occurred, so each one names the behaviour it protects.

Reporting a vulnerability

Send findings to security@purceivo.com. Please include enough detail to reproduce. We will acknowledge within five business days and tell you what we intend to do.

We will not pursue legal action against good-faith research that: uses only accounts you control; does not access, modify or retain another firm's data; avoids degradation of the service (no denial-of-service, no bulk scraping, no automated scanning at volume); and gives us a reasonable opportunity to fix the issue before disclosure.

We do not currently run a paid bug bounty. We will credit researchers who want credit.

What we do not have yet

• No SOC 2, ISO 27001 or comparable audit. None is in progress. If your procurement process requires one, we do not meet it today.
• No third-party penetration test has been performed.
• No paid bug bounty programme.
• Two-factor authentication is built but not yet enforced, and cannot yet be mandated org-wide by an administrator.
• No single sign-on (SAML/OIDC) or SCIM provisioning.
• No uptime SLA, and no formal incident-response time commitment.
• Single region, single instance. There is no multi-region failover; an outage at the hosting region is an outage.
• Backup restores are not yet independently tested on a documented schedule.
• No customer-managed encryption keys and no application-layer encryption of firm data at rest.

If any of these is a blocker for your firm, say so at security@purceivo.com. It is useful to know which gaps actually cost us business, and that is how this list gets shorter in the right order.