Security & privacy
A plain-language summary of how MemberDex handles security, identity, encryption, and data ownership. Use this if a board member, IT contact, or compliance reviewer asks "is this safe?"
Encryption in transit
All MemberDex traffic is HTTPS. We support modern TLS only, with HSTS enabled in production so browsers refuse to fall back to plain HTTP. Static admin assets and the API are served same-origin to prevent cross-origin token leaks.
Authentication
Admins sign in with email + password. JSON Web Tokens are issued for short-lived access (HS256-signed and pinned to that algorithm; we explicitly reject any other signature algorithm). Long-lived refresh tokens are stored in a database table with revocation support.
Refresh-token rotation is race-safe: a conditional UPDATE in a single transaction ensures concurrent refresh attempts with the same token can't both succeed. Concurrent dupes always result in one rotation and one 401.
Multi-factor auth (TOTP)
Each admin can enable TOTP MFA from their account settings. Standard authenticator apps work (1Password, Authy, Google Authenticator). Enabling MFA requires confirming the first code, so you can't lock yourself out by mistake.
10 wrong codes inside an active 15-minute window arms a per-account 15-minute lockout. MFA_LOCKED is returned with HTTP 429. Successful verification or a manual disable clears the counter.
Password policy
Minimum 12 characters, with at least two of the four character classes (lowercase, uppercase, digit, symbol). A common-password blocklist is enforced. Optionally, every password is k-anonymously checked against the Have I Been Pwned breach database — passwords seen in known breaches are rejected.
Audit log
Every login, password reset, invite send, invite accept, role change, deactivation, restore, and admin action writes a row to the audit log. Super-admin impersonation events appear in red on the activity log so community admins always know when a platform engineer has stepped into their tenant.
Data isolation
MemberDex is multi-tenant with row-level org tenancy. Every database query is scoped to the requesting user's org membership; cross-org access requests are rejected even when paths are tampered with. Super-admin cross-org browsing is the exception, and it's audited as impersonation.
Storage
Member data lives in SQLite in WAL mode. Photos are stored as BLOBs alongside their owners — no third-party CDN. Database backups are taken nightly and held in encrypted off-box storage.
Separation from device contacts
MemberDex is a self-contained rolodex. The iOS app does not request access to the iPhone Contacts permission and never writes member records into the device address book. Community members live inside the MemberDex app only; personal contacts on the phone stay personal. There is no merge, no sync, no shared store.
iOS app security
Authentication tokens on iPhone are stored in the system Keychain with kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly — they're only available when the device is unlocked, never sync to iCloud or other devices.
The iOS client uses public-key pinning against the SHA-256 hash of the production server's certificate. Release builds fail closed when the pinning configuration is missing — a misconfigured deploy crashes at startup rather than silently disabling MITM protection.
Webhook integrity
Stripe webhooks are signature-verified before any processing. Side-effect handlers run inside a single SQL transaction so partial failures roll back cleanly. Idempotency keys prevent double-application; failed deliveries are retry-eligible while successful deliveries short-circuit.
Logging
Server logs are scrubbed of sensitive attributes before write. We redact Authorization headers, cookies, password fields, JWT bearer tokens, and webhook secrets at the structured-logging layer.
Rate limiting
Per-IP rate limits apply to login, refresh, public invite reads, password-reset completion, and other sensitive endpoints. The rate-limiter cache caps memory usage and evicts oldest entries when full, so it can't be used as a memory-exhaustion vector.
CSV exports
Member-supplied values that get written to CSV are escaped to neutralize spreadsheet formula injection (cells starting with =, +, -, @). The export streams up to 250,000 rows with a hard cap.
Photo upload
Photos are stored with server-generated filenames; the client's multipart.FileHeader.Filename is ignored at the storage boundary. Content type is sniffed and validated, and only image MIME types are accepted.
Backup & restore
Community archive zips have a per-entry decompression cap and total-size cap. A malicious or oversized archive can't fill disk or balloon memory during restore.
Data ownership and deletion
You own your community's data. You can export the full member list to CSV anytime, or download a community backup zip. Cancellation preserves data through end of paid period; archived communities are deleted after 30 days unless you re-subscribe.
Members can request profile deletion through their community admin. Soft-deactivation removes a member from the directory but preserves audit history. Hard-deletion permanently removes the member row and their photos.
Reporting a security issue
Security issues take priority. Email [email protected] with the subject "Security report" and we'll respond within one business day with an assigned tracking ID and triage notes.