Skip to content
Menu

Security

How Firmiva protects your firm’s data

Firmiva holds client records, so protecting them is part of the design. This page describes the controls built into Firmiva Practice today, and says plainly what isn’t built yet.

Where we are: Firmiva hasn’t launched, and early-access requests aren’t open. It has no production hosting yet and doesn’t hold any security certification.

Every signed-in change

What a change goes through

A change to firm data passes these steps in Firmiva Practice. If a check fails, nothing is written.
  1. 1

    Session

    The session cookie’s random token is matched against its stored hash. Scripts can’t read the cookie.

  2. 2

    CSRF token

    A change must carry a signed token tied to that session.

  3. 3

    Permission

    The action’s permission is checked against the person’s role. Default deny.

  4. 4

    Firm scope

    The query is limited to the person’s firm; for the firm’s work records, row-level security checks it a second time.

  5. 5

    Audit record

    A change to a main record (a client, engagement, project or task, for example) is added to the append-only audit log.

A simplified picture. Request bodies are also validated, and the database’s own constraints apply.

Built today

The controls in Firmiva Practice

Each firm’s data is scoped to that firm

  • Every signed-in request is tied to one person and one firm, and every query of firm data is limited to that firm.
  • PostgreSQL row-level security checks the firm’s work records, such as clients, engagements, projects and tasks, a second time, behind the application’s own checks. Without a firm context, those tables return no rows.
  • Row-level security guards against mistakes in the application. It doesn’t yet protect against a leaked application database password: that hardening is required before production (see below).
  • A record that belongs to another firm is reported as not found.
  • Database keys stop a record from being linked to another firm’s client, engagement, project, task or team member.
  • Automated tests check isolation through the API, in the database and in the browser.

Sign-in and sessions

  • Passwords are hashed with Argon2id and must be at least 10 characters long.
  • Sessions use random 256-bit tokens, and only their hashes are stored. The session cookie can’t be read by scripts.
  • Sessions end on sign-out and after 12 hours by default. Changing your password signs out your other sessions.
  • Repeated failed sign-ins for an account are throttled.
  • Invitation and password-reset links are single-use, time-limited and stored only as hashes, but nothing delivers them yet: email delivery is planned. Until then, invitations work only in development setups and a password reset needs an administrator.

Protection on every request

  • CSRF protection: every change made while signed in must carry a signed token tied to the session.
  • A Content Security Policy that allows scripts only from Firmiva itself, and no HTML is ever rendered from stored data.
  • Every request body is validated, backed by constraints in the database, and queries are parameterized.
  • CSV exports neutralize spreadsheet formulas.

Permissions enforced by the server

  • Default deny: every change to firm data declares the permission it needs, checked against the person’s role. A few read-only views check firm membership only.
  • Among tasks, staff can change only those assigned to or created by them, and can assign tasks only to themselves.
  • Only owners grant owner and admin access, and a firm can’t lose its last owner.

An append-only audit trail

  • Who made a change, to which record, and when; for core records, which fields changed. Recorded for clients, engagements, projects, tasks, workflow templates, notes, the team and firm settings.
  • Not every change is recorded yet: tag and checklist edits, discarding an import and completing a password reset aren’t.
  • A database trigger rejects edits and deletions of audit records, and the application’s database role can only add and read them.

This website

  • Prerendered pages with scripts only from this site: no cookies, no analytics or trackers, and nothing loaded from other websites.
  • A Content Security Policy that allows scripts, styles, images and fonts only from this site, with no inline scripts or styles.

Not built yet

What isn’t in place today

We’d rather you hear it from us.
  • Multi-factor authentication and single sign-onPlanned
  • Password reset and invitations by emailPlanned
  • A hardened database credential, so firms stay separated even if the application’s database password leaksBefore production
  • Production hosting for customer dataNot yet
  • A third-party security audit or certificationNone yet
See the roadmap

Firmiva isn’t generally available yet

Early-access requests aren’t open yet. If you run or work in an accounting firm, see what early access will include and how requests will open.

Early access See the platform