Security at Kasho

Our approach

We keep the attack surface small, separate identity from financial data, encrypt everything in transit and at rest, and grant the least access needed to run the service. We would rather describe a modest set of controls accurately than imply certifications we do not hold.

Identity and access

• Sign-in runs through Sweyam Auth using OpenID Connect with the Authorization Code flow and PKCE. Kasho never sees or stores your password.
• Protected APIs require a short-lived, signed access token (RS256). Every request is verified — signature, issuer, audience, and expiry — before any data is served.
• Access is scoped to the signed-in account. Ownership checks run on ledger records so one account cannot read or change another’s data.
• Sensitive endpoints (such as invitations and discovery) are rate-limited across all server instances, using only hashed identifiers.

Encryption in transit

• All browser and API traffic is served over HTTPS with modern TLS (1.2 or higher, 1.3 preferred).
• Traffic between the application and its object storage is also over TLS.
• HSTS is enabled so browsers refuse to connect over plain HTTP.

Encryption at rest

• The database runs on a dedicated host, separate from the application servers.
• That host sits on a private network and is not reachable from the public internet — only the application can connect to it, over the private link.
• Its storage volumes are protected with LUKS full-disk encryption, and database-level encryption is enabled on top.
• Automated backups are encrypted, stored separately, and restore procedures are tested.

Secrets and tokens

• Invitation and connection tokens are stored only as one-way hashes — the raw token exists just long enough to be delivered to you in a link.
• Deployment secrets (database credentials, signing keys, provider API keys) live in the runtime environment, not in the source code or the repository.

Network and infrastructure

• Application and database run as separate hosts with a private network between them; the database has no public route.
• Servers are hosted in India.
• Operational logs capture request metadata and errors for reliability and abuse investigation; we avoid writing sensitive values into logs.

Data minimisation

• We collect the minimum needed to run the product — see the Privacy Policy for the full list.
• Your financial records are never used for advertising targeting or profiling.
• Free plans may show Google AdMob or AdSense units; those networks receive only standard ad-request technical data, not your ledger contents.
• No third-party session-recording or social-pixel scripts run in the application.

Monitoring and recovery

• Errors and availability are monitored so we can respond to problems quickly.
• Encrypted backups with tested restores protect against data loss.
• We maintain an internal incident-response process (severity, contain, assess, notify). Where personal data is involved we aim to notify affected users and, when required by applicable law (including GDPR Art. 33–34 timelines for EEA/UK users), the relevant authority without undue delay and within 72 hours of becoming aware of a notifiable breach.

Responsible disclosure

If you find a security issue, email [email protected] with details and steps to reproduce. We will acknowledge within 3 working days and keep you updated. We will not pursue action against good-faith research that avoids privacy violations, data destruction, and service disruption, and that gives us reasonable time to fix the issue before disclosure.

What we do not claim

Kasho does not currently hold formal certifications such as SOC 2 or ISO 27001. We describe the controls we actually operate, and we will update this page as that changes.