Security & trust
Isolation enforced by the database, not by discipline.
This page lists the controls that are shipped, the controls that are planned, and the residual risks we know about — in the same words we use internally. If something here is unclear, ask security@residentaxis.com.
Tenancy model
Four enforcement layers
Each customer organisation is a tenant. Isolation is layered so that an application bug cannot, on its own, expose another tenant’s rows.
| Layer | Control | Status |
|---|---|---|
| L1 — Database | PostgreSQL row-level security on every tenant table, FORCEd, with deny-by-default policies (USING + WITH CHECK). A missing tenant context returns zero rows. The API role cannot bypass RLS. | Built |
| L2 — Transaction context | The tenant id is set per transaction (SET LOCAL semantics), so it dies at commit and is safe under connection pooling. | Built |
| L3 — Role scoping | Role guards and narrowing predicates: residents see their lease, owners their doors, vendors their assignments. Verified by cross-tenant probes in CI. | Built |
| L4 — Entitlements | Modules require both an active subscription item and an explicit assignment. Plans are billing bundles, never authorisation. | Built |
| Support mode | Platform staff view a customer workspace only in an org-scoped, audited support session. There is no bypass path. | Built |
Control inventory
Shipped and planned
Labels: Built implemented and tested in the current build · With configured integration implemented, needs deployment configuration · Planned on the roadmap.
| Area | Control | Status |
|---|---|---|
| Access | Role-based access (platform admin, property manager, accounting, leasing agent, maintenance supervisor, owner, resident, vendor) with per-user permission overrides and portfolio scoping. | Built |
| Authentication | scrypt password hashing with per-user salt; timing-equalised verification; password policy and forced rotation; credential lockout (8 failures / 15 min, database-backed). | Built |
| MFA | TOTP two-step login with backup codes and trusted devices. | Built |
| Sessions | Bearer tokens, 256-bit random, only hashes stored; 7-day expiry; hourly pruning; native shell uses 45-day rotating single-use refresh tokens and 4-hour biometric sessions. | Built |
| Audit | Append-only audit log for every write; money, adjustment and signature tables are append-only at the database level (UPDATE/DELETE revoked from the app role). | Built |
| Transport | HTTPS only; HSTS; TLS terminated at the edge proxy with automatic certificate renewal. | Built |
| Security headers | Content-Security-Policy with per-response script nonces, X-Frame-Options DENY, nosniff, Referrer-Policy, Permissions-Policy, COOP — on every response including errors. | Built |
| CORS / CSRF | CORS locked to the configured app origin; cookie-less bearer auth means classical CSRF does not apply; form-action restricted by CSP. | Built |
| Rate limiting | Layered budgets: per-IP on login/signup/reset, per-org write budget, per-key API limits with Retry-After. | Built |
| Input validation | Schema validation on abuse-sensitive routes before any handler runs; all SQL uses bound parameters (mechanical audit: zero interpolated inputs). | Built |
| File handling | MIME allow-list, 10 MB cap, sha256 pinned, scan hook; signed expiring download URLs; path-traversal protection at the storage driver. | Built |
| Secrets | Platform secrets are environment-only; the repository contains none. API keys, webhook secrets and tokens are stored as hashes. | Built |
| Sensitive data minimisation | SSNs are never stored (screening keeps only the provider order reference); bank accounts live at the payment provider; ResidentAxis stores token references and last-4 only. | Built |
| Dependencies | Runtime dependency tree audited; dev-only findings tracked. | Built |
| Deployment separation | Marketing site, product application and database run as separate deployments; the marketing site holds no customer data and is static. | Built |
| Backups | Nightly database dumps with rotation and a pre-deploy backup before every production release; documented restore procedure with a monthly restore drill. | With configured integration |
| Encryption at rest | Database volume encryption is provided by the hosting environment; application-level column encryption for date-of-birth-class fields is planned if such fields are introduced. | With configured integration |
| Multi-instance rate limiting | Shared (Redis-backed) limiter for horizontally scaled deployments. | Planned |
| SSO | SAML / OIDC single sign-on for enterprise customers. | Planned |
| Third-party assessment | Independent penetration test and a SOC 2 readiness review. | Planned |
Residual risks
What we know is not finished
Published on purpose. These are the items on our own list.
- Rate limits are per-process; a horizontally scaled deployment needs the planned shared limiter. Credential lockout is already database-backed.
- Inline styles remain allowed in the app’s CSP (React inline styles); script execution is nonce-only.
- Personal data at rest is not column-encrypted; volume encryption is the deployment’s responsibility.
- Outbound webhooks use HMAC signatures without TLS pinning; secret rotation is manual.
- HSTS preload is not enabled until every host on the apex is HTTPS-only.
- Bearer tokens in browser memory are exposed to any XSS that defeats the CSP; cookie sessions would trade that for CSRF surface.
- Development conveniences (token exposure, localhost CORS) must be off in production; the production contract is documented.
- No independent penetration test has been completed yet.
Operations
Backup, restore and deployment
Backups. Production databases are dumped nightly to the configured storage driver with rotation, and again immediately before every production deployment. Retention and the restore drill cadence are documented in the operations runbook.
Restore. Image rollback is the default recovery; database restore from the pre-deploy backup is the last resort and is announced in the incident log because it rewinds writes.
Deployment. Continuous integration runs the isolation suite, module suites, build and an end-to-end smoke on a fresh database. Releases deploy to staging automatically and to production behind a manual approval gate, with automatic rollback on a failed smoke test.
Data handling. Resident, owner and vendor personal data is processed on behalf of the operator (our customer). Operators control what their portals expose. We do not sell personal data and do not use customer data to train models.
AI features. Optional, approval-gated, and only with a provider the operator configures. Resident personal data is kept out of prompts by design; there is no automated decision-making about applicants or residents.
Sub-processors. Hosting, email, SMS, push, payments, screening and AI providers are configured per deployment and listed in the privacy policy placeholders for the operator to complete.
Responsible disclosure
Found something? Tell us first.
Email security@residentaxis.com with steps to reproduce. We acknowledge within two business days, keep you informed, and credit researchers who wish to be credited. Please do not access data that is not yours, do not degrade service, and give us reasonable time to fix before disclosing publicly.
Privacy questions and data-subject requests: privacy@residentaxis.com. Security questionnaires and DPAs: sales@residentaxis.com.
Send us the questionnaire.
We answer security reviews with the same inventory above, plus the architecture documents on request.