Security Overview

1. Transport and hosting

• degroshi.com and api.degroshi.com are served over HTTPS only (plain HTTP is redirected), through our hosting provider's edge, with certificates managed automatically. The browser never talks to the API directly: requests go through the web app, which validates your session and forwards them server-side.
• The API, web app, PostgreSQL database and Redis run on Railway in the Amsterdam (EU) region, with TLS on the database connection.
• Secrets (database credentials, provider keys, encryption keys) are supplied to the services as environment variables by the hosting platform; they are never committed to source control.

2. Authentication

• Sign-in with email and password (minimum 8 characters, email verification required), Google or Apple. Passwords are hashed by our authentication system (Better Auth); we never store them in clear text.
• Sessions are random tokens stored server-side; the browser holds them in an HttpOnly, SameSite cookie. Web sessions expire after 7 days of inactivity, app sessions after 60 days, and an expired session is removed the next time it is presented. You can sign out of other devices.
• One-time codes for email verification and password reset are stored hashed, expire in minutes and are limited to a few attempts.
• Sign-in, sign-up, password reset and code endpoints are rate-limited per IP; API requests are rate-limited per user.
• API keys you create are stored as hashes and shown only once. External AI clients are authorised through OAuth with your explicit approval and can be revoked.
• Deleting an account requires a session created in the last 15 minutes and typing your email address.

3. Data at rest

• Monobank access identifiers, exchange API keys and secrets, saved-card tokens for subscription renewals, and AI connection credentials are encrypted with AES-256-GCM using a server-held key before they reach the database. Decryption happens only to call the provider.
• Database backups are taken by the hosting provider on the schedules we enable (Railway keeps daily backups for 6 days, weekly for 27 days and monthly for 89 days) and stay inside the same EU region.
• Deleted records are removed immediately; only identifiers of deleted records remain in the sync feed for up to 180 days so your devices can reconcile.

4. Files

• Avatars, space icons, receipts and attachments are stored in a private bucket. Nothing in it is reachable by URL: the API streams a file only after checking that you may see it.
• Uploads are validated by inspecting the file's content, not the name or declared type; images that fail validation are rejected. Receipt images sent to the AI provider are stripped of embedded extra images and metadata segments.
• When a file is replaced or its record deleted, the object is queued and removed from the bucket by a sweeper.

5. Shared spaces

• Every query is scoped to a space, and every write checks your role (viewers are read-only).
• When an owner restricts a member to selected accounts, that member's requests run under a dedicated database role with row-level security policies on every account-linked table. The database, not individual code paths, enforces what they can see, including through the AI assistant, imports and sync. A request with no identified user sees nothing.

6. AI safety

• AI output is only ever a proposal; writes require confirmation in the app, and proposals expire after 24 hours.
• Your records are passed to models as untrusted data, never as instructions, to resist prompt injection.
• Credentials, tokens, card and account numbers and other members' identities are never sent to AI providers. AI observability traces do not capture message content by default.

7. Payments and incoming notifications

• Card details are entered only on monobank's payment page or in Paddle's checkout. From monobank, Degroshi receives a token for the saved card, the masked number and the card network; from Paddle, only the card network and the last four digits. We never receive the full number or the security code. In-app purchases are handled by Apple.
• Payment notifications from monobank are accepted only with a valid signature (ECDSA over the request body, checked against monobank's published key); notifications from Paddle must carry a valid signature (HMAC-SHA256 with a shared secret over the timestamp and body, no older than 5 minutes), and each one is followed by a fresh read from Paddle's API; notifications from RevenueCat must carry a secret authorisation value. A payment is applied only after its state has been confirmed.
• Monobank's notifications of new bank transactions arrive at a secret address, and the regular statement sync is what counts.
• Push notifications do not show amounts unless you turn that on, and are not sent during your quiet hours.

8. Monitoring and operations

• Errors are reported to Sentry in its EU data region (Frankfurt) with credential headers and cookies removed. Metrics, logs and traces go to Grafana Labs with random identifiers only and no financial data. Logs carry a correlation id so a problem can be traced without exposing data.
• Database statements have a server-side timeout; background jobs run with bounded retries.

9. Reporting a vulnerability

If you believe you have found a security issue, email security@degroshi.com with enough detail to reproduce it. We will acknowledge within 3 business days and keep you informed. Please:

• act in good faith, avoid privacy violations, data destruction and service disruption;
• test only against your own accounts and data;
• give us reasonable time to fix the issue before disclosing it.

We do not currently run a paid bug bounty programme.

10. Your part

Use a unique password, keep your devices updated, sign out on shared computers, give exchange keys read-only rights, and tell us immediately at security@degroshi.com if you suspect your account was accessed by someone else. This overview is published in Ukrainian and English; if the two differ, the Ukrainian text prevails.

All documents