SECURITY · UPDATED 23 SEPTEMBER 2026
How we protect your project records
This page describes the controls built into Timastra Expenses and its reference deployment. It states what is implemented today; it is not a certification, and Timastra Expenses does not currently hold third-party security certifications. No system can guarantee absolute security.
Production data is hosted in Philippines. Service providers: VPS hosting provider, Resend, Stripe.
Workspace isolation
- Every customer works in a separate organization workspace. Each session is bound to one workspace, and every query for workspace data is filtered by that workspace on the server.
- Isolation is enforced in the application's data access code; the database does not use row-level security policies.
- Engineers see only the projects they lead or crew. Receipt files are stored under a per-workspace path and are served only after the same authorization check.
Access control and sessions
- Roles (administrator, manager, finance, engineer, auditor) are enforced on the server for every request. Hiding a button is never the control.
- Approval requires a different person from the one who created or last changed a liquidation. An administrator exception must carry a reason, and every exception appears in the auditor's self-approval report.
- Sessions use Secure, HTTP-only cookies backed by a server-side record, so they can be revoked at once. They expire after 30 minutes idle by default and after 12 hours in all cases.
- Passwords are stored as bcrypt hashes. Repeated failed sign-ins lock the account, requests are rate limited, and state-changing requests must come from the application's own origin.
Sign-in protection
- Platform operators sign in with a password plus a one-time code sent by email, and repeat it before sensitive actions.
- Workspace members can protect their accounts with an authenticator app or a passkey, and administrators can require it for everyone.
- Administrators can connect their identity provider for single sign-on and provision members with SCIM.
- Email verification, invitation and password recovery links are single-use, expire, and are stored only as hashes.
Audit trail
- Approvals, reversals, deposits, member changes, exports and other changes are written to an audit log with the actor, time and before-and-after values.
- Audit rows are protected against update and deletion by database triggers, and each workspace's rows form a SHA-256 hash chain that can be verified independently of the application. Editing, removing or inserting a row out of band breaks the chain.
- Financial records are corrected by reversal, never deleted. Opening a receipt is itself logged, so auditors can see who viewed which evidence.
Encryption
- All traffic to the service uses HTTPS with automatically renewed certificates. Production responses send HTTP Strict Transport Security.
- The production deployment requires encrypted storage for the database, receipt files and backups; the service reports itself not ready until the operator confirms it. This confirmation is an operator attestation, not a cryptographic check.
Backups and recovery
- Backups capture a consistent PostgreSQL snapshot together with the matching receipt files, record a checksum for every file, and are replicated to separate storage. They are kept for 30 days by default.
- A restore verifies every checksum and the audit chain before loading into a fresh, empty database, and never overwrites the original.
Application security
- Uploaded receipts are identified by their content, not their name, and limited in size. They are served with a sandboxed content security policy, so a file cannot run code in the application.
- Pages send a strict content security policy and refuse to be framed. CSV exports neutralise cells that a spreadsheet could run as formulas.
- Card details are entered on the payment provider's pages and never reach Timastra Expenses.
- The code has been reviewed internally against OWASP ASVS 5.0 and the OWASP Top 10 (2025). This is an internal review, not a certification.
Your data
- Workspace administrators can export their workspace's records. Exports exclude credentials, sessions and token hashes.
- Closing a workspace follows a documented retention period with legal holds; erasure must be approved by a second platform owner and leaves a signed deletion record.
Reporting a vulnerability
Report a suspected vulnerability privately to [email protected]. Include the affected page or feature, how to reproduce it and the likely impact. Do not include passwords, receipt images or customer data, and do not publish details before a fix is available.
We aim to acknowledge reports within three business days, confirm the severity, prepare a fix and coordinate disclosure once affected deployments have had time to update. Test only against your own workspace with synthetic records; never against another customer's data.