Security

• People sign in with their Google account through Firebase Authentication. Every sign-in token is verified on our server: its signature against Google’s published keys, and its issuer, audience and expiry.
• Studioflow stores no passwords.
• A session is a long random token. Only a SHA-256 hash of it is stored, so the database never holds a usable session.
• The session cookie is HTTP-only and marked secure: page scripts cannot read it, and it is only sent over encrypted connections. Sessions expire after 30 days, and active sessions can be reviewed and signed out.
• Sign-in attempts are rate limited.

• Every read and every change is authorized on the server: the workspace, your membership and role, and the specific record are checked on each request. A workspace or record identifier in a link grants nothing on its own.
• Roles carry specific capabilities. The roles are owner, admin, finance, project lead, member, contractor, client guest.
• Internal cost rates and margins need a separate permission. For people without it, those values are removed from what the server sends, not just hidden in the interface.
• Client guests receive only the records shared with them. Internal comments, costs and margins are never included in what is sent to them.
• When a workspace is in restricted access, for example after a trial ends without a plan, new work is blocked on the server while existing records stay readable and exportable.

• Requests that change data must be sent as JSON with an application header, which blocks cross-site form submissions.
• Actions that a double click or a retry could repeat, such as creating, issuing, sending or paying, carry an idempotency key so they take effect once.
• Financial rules are enforced by the database itself: issued invoices cannot be changed or deleted, a piece of work can be billed only once, submitted and approved time is locked, and an accepted change request is applied exactly once.

• Card payments happen on Stripe-hosted pages. Card details never pass through or are stored by Studioflow.
• Subscription billing and client invoice payments are kept apart. A studio’s client payments go to that studio’s own connected Stripe account.
• Stripe events are verified by their signature, recorded once and processed so that repeated, delayed or out-of-order events produce one correct result. A success page alone never marks an invoice paid or grants paid access.

• Financial, permission and destructive changes are recorded with who made them, when, the record affected and, where relevant, the values before and after.
• Secrets and private calendar contents are not written to the audit log.

• Uploaded files, such as receipts, are kept in private storage. Downloads go through signed links that are issued only after an access check and expire after 15 minutes.
• Traffic to the app is encrypted in transit with HTTPS.

• Rate limits apply to sign-in, to creating sample studios and to the contact form. Their counters are keyed by one-way hashes rather than raw IP addresses or email addresses.
• Sample studios are isolated. They never send email, take payments or reach external services.
• Email is sent only through the platform’s email service, and its status is recorded as reported: an email accepted for delivery is not shown as delivered.

• Studioflow has not completed a third-party security audit or certification, such as SOC 2 or ISO 27001, and does not claim one.
• There is no SAML single sign-on or SCIM provisioning. Google sign-in is the supported way to sign in.
• No uptime, recovery time or data loss guarantees are offered.

These are not in place as published commitments yet. They will be described here once they are established and reviewed:

• Backup frequency, how long backups are kept, and a tested restore procedure.
• Incident response steps and timelines for notifying affected studios.
• Retention periods for each type of record after a workspace is deleted.
• Independent penetration testing.

If you believe you have found a security issue, tell us through the contact page with the topic “Report a security concern”, including the steps to reproduce it. Please do not access data that is not yours, and do not degrade the service while testing.