Security posture
Settle The Tab is built around least privilege, private-by-default data, server-checked authorization, encrypted transport, auditable changes, safe retries, and tested recovery. We avoid placing expense descriptions, receipt contents, passwords, authentication tokens, and API keys in ordinary logs.
No online service is perfectly secure. These are practical controls, not a guarantee or independent certification. Protect your device, review group membership, and report unexpected access promptly.
How data is protected
Encrypted connections
Public web and API traffic uses HTTPS. Private application, database, and receipt-storage connections use authenticated TLS.
Private storage
Ledger data and receipt objects are stored on a private data tier that is not directly exposed to the internet.
Server-checked access
Group membership, role, and object scope are checked for every protected request. Knowing an identifier is never permission.
Restricted credentials
Production secrets stay outside source control in protected service files. Application, migration, and backup permissions are separated.
The web service uses same-origin and CSRF protections for cookie-authenticated changes, constrained cross-origin access, input validation, parameterized database operations, security headers, and rate limits on risky endpoints. Every synchronized mutation has a unique operation ID and revision precondition so retries do not create duplicates and concurrent money edits are not silently overwritten.
Identity and access
- Email passwords are hashed with Argon2id. Plaintext passwords are not stored.
- Web sessions use Secure, HTTP-only cookies. Native iOS session credentials are stored in Keychain.
- Apple and Google sign-in use provider identities and standard authorization protections. We do not receive those provider passwords.
- Invitation, verification, and reset tokens are random, purpose-limited, expiring, and stored as hashes where applicable.
- AI API keys are shown once, stored only as a one-way digest, limited to the user's ordinary permissions, and revoked when rotated.
- Account deletion, export, provider linking, and other sensitive actions require a current or recently confirmed session.
Receipt safety
Receipt files live in private object storage and can be opened only through an authorized request tied to the group and parent expense. Original filenames do not become public object keys, bucket listing is disabled, and a failed receipt upload does not erase the expense.
The upload pipeline enforces byte, media, signature, and pixel limits. Supported images are decoded and re-encoded as bounded JPEGs before permanent storage, which removes EXIF, GPS, and other embedded image metadata.
Metadata removal is not redaction. A visible name, address, loyalty number, card fragment, or other printed detail remains in the image. Crop or redact unnecessary details before uploading.
Device security
Web records are cached in IndexedDB and iOS records in SwiftData so the app can remain responsive and useful without a connection. Someone with access to an unlocked device or browser profile may be able to see that cached information. Use device encryption and a screen lock, avoid shared browser profiles, and remove access from devices you no longer control.
Screenshots, exports, device backups, browser extensions, and notification previews can create copies outside the service's direct control. A queued local change can still be rejected by the server after permissions change or when another edit creates a conflict.
Operations and recovery
Production services run under dedicated accounts with host firewalls, restricted network paths, automatic security updates, resource limits, health checks, log rotation, and deployment rollback. The database and receipt store are not directly public.
Encrypted database and receipt backups retain multiple generations. Restore drills verify that ledger records and receipt objects can be recovered together. Backup access is separate from ordinary application access, and deleted data ages out according to the retention policy.
Report a vulnerability
Email support@settlethetab.com with a subject beginning SECURITY:. Include a concise description, the affected feature or URL, likely impact, approximate time, and minimal repeatable steps using accounts and groups you control.
Remove passwords, session cookies, API keys, email addresses, financial details, and receipt contents from screenshots or logs. Do not access another person's data, use phishing or credential attacks, send malware, disrupt availability, run bulk scans, or test third-party providers. Stop and report immediately if you encounter information that is not yours.
There is no paid bug-bounty program. Good-faith reports are welcome, but this page does not authorize unlawful activity or testing outside accounts and data you control.