Security & Privacy

Customer records are protected with database-level access rules in addition to interface controls. Customer-facing reads are scoped to the authenticated account where the underlying record supports customer access, while administrative operations require elevated authorization.

• Access rules are enforced at the data and backend layers rather than relying only on hidden interface controls.
• Cross-account access and direct-API abuse are included in security testing and remediation.
• Consequential client writes are routed through controlled backend actions or restricted to administrator access.

Sensitive internal information such as staff-only notes, Stripe linkage identifiers, and protected operational credentials is kept in administrator-restricted records where those values are required by the application. Customer-facing flows are not intended to expose those records directly.

• Administrative fields are separated from customer-editable data where practical.
• Customer actions use allowlisted backend inputs so internal state is not accepted simply because a browser submits it.
• Administrator-restricted entities require an administrator role for direct create, read, update, and delete operations.

Consequential actions such as order-state changes, document review, protected client submissions, and other privileged mutations use backend enforcement or administrator-only entity rules. Those boundaries verify identity, role, ownership, and permitted fields as appropriate to the action.

• Identity and role checks are performed server-side for protected actions.
• Controlled client gateways use explicit field allowlists rather than accepting arbitrary record payloads.
• Administrative review and commercial state are not authorized merely by values submitted from the browser.
• Interface visibility is treated as usability; authorization is enforced separately at the backend and data layers.

Current compliance-document upload flows use Base44 private file storage and short-lived signed links for authorized access. The application also blocks permanent HTTP(S) file references from being opened through its secure-file helper.

• Current private document views generate temporary signed access links that expire automatically.
• New compliance-file upload paths use private file URIs rather than permanent public URLs.
• Historical storage references are treated separately from current upload behavior and are not considered resolved solely because a database record was updated.
• Protected upload and document-record creation paths require authenticated or administrator-controlled authorization as appropriate.

We perform security-focused testing against important application boundaries, including cross-account reads, privilege boundaries, hidden or administrative field writes, URL and ID manipulation, payment-state handling, and file access.

• Findings remain open until the relevant control is repaired and re-tested; a code change by itself is not treated as proof of closure.
• Security testing reduces risk but is not represented as a guarantee that a system has zero vulnerabilities.
• Live-data checks are included when a finding depends on stored records rather than source code alone.

Important administrative and security-relevant actions are logged where the application has an audit event for that workflow. These records support investigation and accountability, but they are not described as a complete record of every action in the system.

• Audit coverage includes selected document, onboarding, commercial, support, and administrative events.
• Logging coverage is reviewed alongside the workflow itself so the interface does not overstate what has actually been recorded.