Data security
This page describes the controls implemented in the Booksmrt application and the work that is still required. It does not substitute marketing language for independent evidence.
Implemented controls
These controls are part of the deployed code path and are checked again during production readiness review.
Client passwords alone cannot open financial data. Clients enroll and verify an authenticator, receive single-use backup codes, and complete a second-factor check at sign-in. Factor replacement requires existing-factor proof; password resets do not disable 2FA. Authenticator codes are not phishing-resistant passkeys.
Client uploads are transferred to a restricted Google Drive folder. The portal stores an encrypted Drive reference and bookkeeping metadata, not a second copy of the uploaded statement. File bytes exist in application memory only while the upload is inspected, transferred, and parsed.
The full portal-state payload is encrypted with AES-256-GCM before it reaches Supabase. Authentication, QuickBooks tokens, Drive references, and audit fingerprints use separate keys so one secret is not reused across systems.
Production credential storage is disabled. Booksmrt uses OAuth, accountant invitations, named read-only access, or an approved external password vault instead of asking clients to save bank and payroll passwords here.
Portal and admin routes enforce separate roles. State-changing requests check origin, private responses are not cached or indexed, sign-in and sensitive actions are rate-limited, and production sessions expire after 12 hours.
Security-sensitive actions create an audit event. Raw IP addresses and full browser user-agent strings are replaced with keyed fingerprints and a coarse browser label before they are persisted.
Deterministic bookkeeping remains available without an AI provider. Sending statements, transaction details, or financial summaries to an external model requires both a provider key and a separate financial-data approval switch.
Data boundaries
The portal collects less, sends less, and refuses a request when it cannot preserve the expected boundary.
PostHog replay and analytics, Meta Pixel, Google Analytics, and AdFlint are limited to public marketing pages. Portal and admin pages stop replay and use a CSP that excludes those third parties.
The portal checks file type, size, archive expansion, unsafe archive paths, active PDF content, Office macros and embedded objects, image dimensions, and recognizable credential material before handoff.
The handoff removes unexpected direct permissions, corrects expected roles, disables editor resharing, and refuses to upload when broader inherited access cannot be removed at the client-folder level.
Portal passwords use a 15-character minimum, contextual and common-password rejection, a versioned pre-hash, and bcrypt. Existing sessions do not expose password hashes to the browser.
No website can honestly promise that data can never be hacked. The remaining controls below should be treated as production gates for higher-risk use, not hidden as future polish.
Open security work
Security claims will be updated only when the supporting control has been implemented and independently verified.
No completed third-party penetration test is claimed yet. One is required before representing the portal as independently tested.
The application does not yet enforce MFA for portal administrators. Production access should be restricted until passkeys or another phishing-resistant second factor is implemented and verified.
The application preflight is not an antivirus or content-disarm system. A managed malware scanner and CDR workflow are required before accepting files at broad production scale.
Booksmrt is not claiming SOC 2, HIPAA compliance, a completed security audit, or insurance coverage on this page. Those claims require current independent evidence.
We can explain the implemented controls, data flow, and remaining production requirements before you share financial documents.