Security

Wocha is an authentication and authorisation platform built for multi-tenant SaaS and enterprise workloads. This page describes our security architecture, operational controls, and how to report vulnerabilities.

---

Security architecture overview

Wocha Cloud runs on a layered architecture:

Each customer tenant receives an isolated database schema containing their identity, OAuth, and permission data. Platform metadata (tenant registry, branding, audit events) lives in a shared greet_platform schema with strict access controls.

---

Data encryption

Encryption in transit

All customer-facing endpoints enforce TLS 1.2 or higher. Internal service-to-service traffic between platform components is encrypted on the wire within our production network.

• Hosted login: https://{tenant}.auth.wocha.ai
• Customer API: https://{tenant}.api.wocha.ai or https://api.wocha.ai
• Console: https://console.wocha.ai

Management API keys and OAuth client secrets must only be transmitted over HTTPS. SDKs and CLI tools refuse plaintext credentials in production configurations.

Encryption at rest

Database volumes and object storage used by Wocha Cloud are encrypted at rest using provider-managed keys. Sensitive credentials stored in the platform (API key hashes, webhook secrets, connection secrets) are hashed or encrypted before persistence — raw secrets are shown only once at creation.

---

Key management

JSON Web Key Set (JWKS) signing keys for OAuth access tokens and ID tokens are stored exclusively in HashiCorp Vault Transit. Hydra and Kratos never hold private signing material; they request signatures via Vault's Transit API.

Benefits of this model:

• Rotation without downtime — key version rotation is a Vault API operation; relying parties pick up new public keys via JWKS
• Audit trail — Vault audit logs record every signing operation
• HSM upgrade path — Vault Transit can be backed by cloud HSMs without changing application code

See our internal ADR on JWKS in Vault Transit for design rationale.

---

Network security and isolation

• Tenant isolation — requests are scoped to a single tenant via subdomain, JWT claims, or X-Tenant-ID headers before any data access
• Private networking — database, Vault, and internal admin endpoints are not exposed to the public internet
• Rate limiting — Customer and Account APIs enforce per-key and per-IP rate limits with standard X-RateLimit-* response headers
• Webhook egress controls — outbound webhook delivery uses DNS pinning to prevent server-side request forgery (see below)

---

Schema-per-tenant data isolation

Every Wocha Cloud tenant receives a dedicated CockroachDB schema (tenant_<slug>) containing:

• Kratos identity and session tables
• Hydra OAuth client and consent tables
• SpiceDB relationship data scoped to the tenant

Cross-tenant queries are prohibited at the application layer. The control plane accesses only the shared greet_platform schema for tenant lifecycle operations. This model provides logical isolation equivalent to dedicated databases without the operational overhead of per-customer clusters.

---

Authentication security

Wocha runs Ory Kratos with a hardened production configuration:

• Password policies — minimum length, breach detection via Have I Been Pwned (where enabled)
• MFA — TOTP and WebAuthn/passkeys supported; enforceable per organisation
• Session hardening — secure, HTTP-only cookies; session revocation via Customer API
• Account enumeration mitigation — consistent response timing on unknown credentials
• Brute-force protection — rate limits on login and recovery flows

Hosted login UI runs on tenant-specific subdomains with strict Content Security Policy headers.

---

OAuth 2.1, PKCE, and DPoP

Wocha implements modern OAuth best practices:

SDK packages (@wocha/nextjs, @wocha/react, etc.) enable PKCE by default and support optional DPoP via configuration.

---

SSRF protection for webhooks

Outbound webhook delivery resolves the target hostname to IP addresses before connecting and pins the connection to those addresses. This prevents attackers from registering webhook URLs that redirect to internal services (metadata endpoints, localhost, private RFC 1918 ranges).

Additional webhook safeguards:

• HMAC-SHA256 payload signing with per-subscriber secrets
• Exponential backoff retry (up to 10 attempts)
• Delivery logging and manual replay from the Console
• Optional event filtering per subscriber

---

Audit logging

Wocha maintains a durable audit event stream in the greet_platform.audit_events table. Events are schema-validated at write time and include actor, resource, action, and timestamp metadata.

Audit events cover administrative actions such as API key creation and revocation, SSO connection changes, SCIM provisioning, and permission updates. Enterprise plans include audit log export via the Customer API (GET /logs?type=audit).

Authentication events (login success/failure, MFA challenges) are available separately via GET /logs?type=auth.

---

Vulnerability management

We operate a continuous vulnerability management programme:

1. Dependency scanning — automated CI checks on all SDK and service repositories
2. Container scanning — production images scanned before deployment
3. Patch cadence — critical CVEs addressed within 72 hours; high severity within 7 days
4. Penetration testing — annual third-party assessment; findings tracked to remediation

Security patches are deployed through our standard release pipeline with changelog entries for customer-visible changes.

---

Responsible disclosure

If you discover a security vulnerability in Wocha Cloud or our open-source SDKs, please report it responsibly:

Email: security@wocha.ai

Please include:

• A description of the vulnerability and its impact
• Steps to reproduce (proof of concept if available)
• Affected URLs, tenant slugs, or SDK versions
• Your preferred contact for follow-up

We aim to acknowledge reports within 2 business days and provide a remediation timeline within 5 business days for confirmed issues. We do not pursue legal action against researchers who follow responsible disclosure practices and do not access customer data beyond what is necessary to demonstrate the issue.

We currently do not operate a paid bug bounty programme; recognition in our security advisories is offered with your consent.

---

Incident response

Wocha maintains an incident response plan covering detection, containment, eradication, recovery, and post-incident review.

Monitor active incidents on the Wocha status page. Enterprise customers receive direct notification for incidents affecting their tenant or region.

---

HIPAA compliance

Wocha Cloud supports HIPAA compliance through per-tenant opt-in with automatic technical safeguard enforcement. When HIPAA mode is enabled:

• MFA is mandatory for all users accessing the tenant
• PHI fields are classified in a field registry and automatically filtered from tokens and API responses
• Session timeouts are enforced with HIPAA-compliant minimums (5-minute idle, 60-minute absolute)
• Field-level access logging records every PHI access in the audit trail
• 6-year WORM retention is applied to all audit events
• Breach notification workflow provides HHS reporting templates per 45 CFR 164.404-408

Healthcare customers must accept a Business Associate Agreement before enabling HIPAA mode. See the HIPAA compliance guide for detailed setup instructions.

---

Related documentation

• Compliance overview — certifications, GDPR, and data residency
• HIPAA compliance guide — enabling HIPAA mode
• Business Associate Agreement — HIPAA BAA template
• Service level agreement — uptime commitments by plan tier
• Data Processing Agreement — GDPR data processing terms