Security overview.

Data in transit is encrypted using TLS 1.2+. Data at rest is encrypted with AES-256 by the hosting platform — a control we inherit from Base44 rather than implement, so it rests on that platform's own attestation and not on anything in our code. Onboarding document uploads are stored as private files and opened only through short-lived signed URLs — 15 minutes for reviewers, 5 minutes for the malware scanner; they are queued for scanning at upload and scanned when the application is submitted. Attachments sent through an applicant's "more information" reply or a verification-link response, and documents uploaded before private storage was introduced, still use a stored file URL rather than a signed one. Every response carries a Strict-Transport-Security header (two years, including subdomains), X-Content-Type-Options and a Referrer-Policy. The Content-Security-Policy is generated from a single source file and is enforced today as a meta policy in the document, not as a response header; the only CSP the edge returns as a header is frame-ancestors 'none'. That gap is real, it is why an external scanner reports our CSP as permissive, and it is described under Testing and known gaps below.

Designated sensitive fields — EIN, banking details (routing and account numbers), and signer government-ID image references — carry an additional layer of per-tenant AES-256-GCM application-layer encryption. They are made readable only to an owner, admin or reviewer — never a viewer — through an explicit, second-factor-gated, audit-logged decrypt action that reveals the full values. Applicants cannot invoke that decrypt; the one applicant-facing exception is a nonprofit's own previously entered manual bank details, carried forward to pre-fill its next application. Everywhere else — accounts verified through Stripe or GIACT, cross-tenant fraud matches, the shared negative file, and your own billing payment method — bank-account values appear only as their last four digits.

For cross-tenant fraud matching, identifiers are compared as keyed, non-reversible hashes — never as raw values — so no clear identifier is pooled across enterprise workspaces.

Per-tenant encryption keys, webhook signing secrets, and payment-method tokens are held in a dedicated, service-role-only secret store. They live on records that no tenant member can read — not owners, not admins — and are reachable only by backend functions, never by the browser or any client query.

Applicant and workspace data is stored and processed in the United States. The two rows that are not US-only — Cloudflare’s edge challenge and the IP-geolocation lookup — receive network metadata, never submission data.

Two things test this platform today, and neither is a third-party penetration test. A continuous scanner (Aikido) watches the repository and the running application — its external audit report is linked in the footer of every page. And an admin-run self-test probes our own public surface for the vulnerability classes that report covers: authentication, sensitive-data exposure, response headers, TLS and hardening. It is read-only, it is run by us, and we would rather call it what it is than dress it up as an engagement.

Two findings are open, both about response headers rather than application logic: the full Content-Security-Policy is delivered as a meta policy in the document instead of as a header, so a scanner reads the header-level policy as permissive and neither frame-ancestors beyond 'none' nor a fallback directive is enforced at that layer. The policy is generated from one source file and the header values are emitted at build time; deploying them at the edge is a configuration step that has not been completed. Until it is, this page says so.

We have not commissioned an independent penetration test or a SOC 2 or ISO 27001 audit. The readiness badges above say "self-assessed" for that reason.