Website Security Policy

All traffic to and from the service is encrypted with TLS (HTTPS). HTTP requests are redirected to HTTPS and HSTS is set. Data at rest — the database, backups and uploaded evidence files — is encrypted by our infrastructure providers.

The service is multi-tenant on a shared database. Every tenant row carries a workspace id and is fenced off by PostgreSQL Row-Level Security, so a query can never read or write another workspace’s data. Uploaded evidence files are stored in a private bucket under a path that begins with the workspace id, and the same row-level rules govern who can list, read or delete them. Files are never public; each download is a short-lived signed link.

Accounts are protected by email and password. Passwords are stored only as salted hashes by our authentication provider and are never visible to us. Sessions use signed, http-only cookies and are refreshed server-side. A forgotten password is reset by an emailed, single-use link that expires after about an hour.

Two-factor authentication (2FA) is mandatory on every account. It uses a standard authenticator app (TOTP — Google Authenticator, Microsoft Authenticator, 1Password, Authy and similar). You set it up as part of creating your account and cannot reach the application without it; a one-time code is then required at every sign-in. You can replace your authenticator at any time from Your account, but an account with no authenticator is sent straight back to set one up.

Passwords are held to the following rules, which the app enforces:

• Length & make-up — at least 12 characters, and must contain an uppercase letter, a lowercase letter, a number and a symbol. The requirements are shown live as you type.
• Reuse — you cannot set a password matching any of your last 4.
• Failed sign-ins — after 6 failed attempts an account is locked for 30 minutes; a password reset clears the lock immediately.
• Maximum age — a password expires 90 days after it was last set. At the first sign-in after it expires you are required to choose a new password before you can reach the application, and an active session is redirected to the change-password screen once the 90 days pass. This is enforced by the app, not just advised.
• Idle timeout — a signed-in session ends automatically after 30 minutes of inactivity and you must sign in again. Activity in any open tab keeps it alive.

Change your password, and manage your authenticator, from Your account inside the app.

Within a workspace, access follows role: owners manage members and billing, editors can change control status and attach evidence, viewers are read-only. Server actions re-check the caller’s role and workspace membership on every write, on top of the database rules.

Payments are handled by Lemon Squeezy, LLC as Merchant of Record. Card details are entered on Lemon Squeezy’s systems, not ours — we never receive or store full card numbers. See the Privacy Policy for the data we do receive.

The application is hosted on managed platforms (Vercel for the app, Supabase for the database, authentication and file storage). Patching of the underlying operating systems, databases and runtimes is handled by those providers. Administrative access to production is limited to Kim and protected by 2FA.

The database and file storage are backed up by our infrastructure provider on a rolling schedule, with point-in-time recovery on the production plan. You can export your own workspace data to CSV or PDF at any time and should keep your own copies of anything business-critical.

• input is validated on the server before it reaches the database;
• security headers are set on every response (HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a restrictive Referrer-Policy and Permissions-Policy);
• the app framework provides cross-site-scripting and CSRF protections, which are kept enabled;
• dependencies are kept current and reviewed for known advisories;
• secrets (API keys, the database service key, the payment webhook secret) are stored only as environment variables and are never committed to source control or exposed to the browser.

• use a strong, unique password and enable 2FA;
• only invite people who should see the workspace, and set each person’s role to the least access they need;
• remove members promptly when they leave;
• tell us at once if you think an account or device has been compromised.

If you believe you have found a security vulnerability, email kim_abdalian@yahoo.com with the words “security report” in the subject and enough detail to reproduce it. Please do not publicly disclose the issue until we have had a reasonable chance to fix it, and do not access or modify data that is not yours while testing. We will acknowledge your report, keep you updated, and credit you if you would like.

If a security incident affects your personal data, we will notify affected workspace owners and any regulator as required by law, describe what happened and what we have done, and tell you what you should do. Material changes to this policy are announced by email or in the app.

Security questions: kim_abdalian@yahoo.com. See also our Terms of Service and Privacy Policy.