Security you can verify.
We treat security as engineering, not a badge. The controls below are the ones actually in place today — described plainly, so you can hold us to them. The headline is tenant isolation enforced by the database and proven by automated tests, not a promise in a brochure.
- RLS
- Enabled & forced
- Argon2id
- Password hashing
- TLS
- Encrypted in transit
- Sign-off
- Required to go live
One tenant can never read another's data.
Multi-tenant isolation is enforced by PostgreSQL row-level security — ENABLED and FORCED on tenant tables, applied by a non-superuser application role that cannot bypass it. Cross-tenant reads return zero rows and cross-tenant writes are rejected at the database, and automated isolation tests verify exactly that on a continuous basis.
RLS enabled and forced
Row-level security is ENABLED and FORCED on tenant tables, so every query is filtered by tenant at the database itself — not just in application code.
No superuser bypass
The application connects as a non-superuser role with no ability to bypass RLS. There is no privileged path around the tenant boundary.
Continuously verified
Automated isolation tests assert that cross-tenant reads return zero rows and cross-tenant writes are rejected at the database — every run, not a one-time check.
Restrictive in-tenant controls
Sensitive modules (HR, payroll, performance reviews, documents) add RESTRICTIVE database policies for record ownership, sharing, roles, and location scoping.
Proven, not asserted. The isolation guarantee is backed by tests that attempt cross-tenant access and confirm the database refuses it — so the boundary is checked, not assumed.
Strong credentials, narrow access.
Identity is protected with modern password hashing and optional two-factor, and what each person can see is scoped by role, ownership, and location.
Argon2id password hashing
Passwords are hashed with Argon2id, a modern memory-hard algorithm — never stored in plaintext, never recoverable.
Optional two-factor (TOTP)
Accounts can enable time-based one-time-password (TOTP) two-factor authentication for a second layer at sign-in.
Role-based access control
In-tenant visibility follows roles, record ownership, sharing, and location scope, so people see only what their role permits.
Hashed & scoped tokens
Session tokens are stored only as SHA-256 hashes. Public share links use unguessable 256-bit random capability tokens with explicit scope and expiry.
Your records, guarded in motion and at the boundary.
Data is encrypted in transit, confined to your tenant by the database, handled by least-privilege roles, and every meaningful action is written to an append-only log.
Encrypted in transit
Traffic is protected with TLS, terminated at the edge, so data moving between browsers and the platform is encrypted.
Tenant isolation by default
The same forced row-level security that separates tenants guards every read and write to your business records.
Least-privilege database roles
The application never runs as a database superuser, and migrations run under a separate role — privilege is granted narrowly and deliberately.
Append-only audit logs
Platform and tenant actions are recorded to append-only audit logs, so activity leaves a durable, ordered trail.
Layered defenses against automated abuse.
Multiple independent controls raise the cost of scraping, credential stuffing, and probing — and the admin surface simply isn't there unless you know where to find it.
Proof-of-work challenges
Sensitive endpoints can demand a proof-of-work challenge, raising the cost of automated abuse.
Datacenter & FCrDNS filtering
Datacenter-IP filtering and forward-confirmed reverse-DNS (FCrDNS) verification separate legitimate crawlers from impostors.
Rate limiting & lockout
Sliding-window rate limiting and brute-force lockout throttle and stop credential-stuffing and flooding.
Secret-host admin gate
The admin control plane is unreachable — it returns 404 — anywhere except a secret host, with defense-in-depth checks behind that gate.
Measurement without surveillance.
We built our own analytics so we don't hand your visitors to anyone else. It's first-party and cookieless, uses anonymized visitor IDs that rotate every day, and runs on the same sovereign, self-hosted stack as the rest of the platform.
Cookieless & first-party
Analytics are first-party and cookieless, with anonymized visitor IDs that rotate daily — no cross-site profiles.
No third-party trackers
There are no third-party ad or analytics trackers embedded in your pages or admin surface.
Sovereign, self-hosted stack
Database, application, analytics, email, and geo-lookup are self-hosted on one stack, minimizing third-party data exposure.
Independent review, before anything ships.
Security isn't self-graded by the team building features. A dedicated platform security function provides continuous oversight and must sign off before anything goes online, and hardened response headers are applied at the edge.
Independent security oversight
A dedicated platform security function reviews the platform continuously, independent of the teams shipping features.
Required pre-online sign-off
A security sign-off is required before anything goes online — release is gated on that review, not bypassed under deadline.
Edge security headers
Responses carry HSTS (with preload), X-Content-Type-Options nosniff, X-Frame-Options DENY, and a restrictive Permissions-Policy.
Found something? We want to hear from you.
If you believe you've discovered a security issue, please report it to us privately. We commit to acknowledging reports and working in good faith with researchers to understand and resolve them. Please give us a reasonable chance to fix an issue before disclosing it publicly.
Run your business on a foundation you can trust.
The same care that isolates your data at the database goes into every part of WoneSuite. Get started free, or talk to us about your requirements.
Security is continuously improved; this page reflects the controls in place today and is updated as they evolve.