Security
How we protect your data in costwise.pro
Security is not an add-on for us — it is built into the platform architecture. Below we describe the mechanisms that actually run in production and what your company can do on top of that to further raise the protection of your data.
What we do on our side
Strict multi-tenant isolation
Every company on the platform runs inside its own tenant identified by tenant_id. All key database tables have Row-Level Security (RLS) enabled and access policies compare the logged-in user's tenant_id with the record's tenant_id. As a result, a user of one company technically cannot read data of another company — even in case of a bug in the application layer.
Authentication and session management
Sign-in is based on email + password and optional Google OAuth. Sessions are managed on the backend and tokens are refreshed automatically. We do not allow open registration — accounts are created only via invitation, manual creation by an administrator, or plan purchase. Invitations are time-limited (7 days) and the single-use link can be used only once.
Password policy
The minimum password length is 8 characters. Temporary passwords generated at account creation are 12 characters and force a change on first login — until the password is changed, the user has no access to the dashboard. Passwords are not stored in plaintext.
Roles and permissions
User roles (Admin, Manager, Controller, Finance, User, etc.) are stored in a separate table — never on the user profile — which prevents privilege escalation attacks. Visibility of financial data is limited to Admin, Manager, Controller and Finance roles only. The platform superadmin operates in a separate space and does not have direct access to tenants' operational data.
File validation and verification
Uploaded files are capped at 5 MB. File type is validated not only by extension, but also by verifying the so-called magic bytes — the file's binary header. Images are additionally scaled on the client to a maximum width of 1600 px, which limits the risk of heavy uploads and makes it harder to hide content in metadata.
Secure API layer (edge functions)
Sensitive operations go through edge functions which explicitly validate input, return errors in a structured format, and never expose internal project identifiers. Backend service keys are not accessible on the client — not even to the tenant administrator.
PWA without hidden cache
The app runs as a PWA, but deliberately does not use Service Workers or aggressive caching — data is always fetched fresh from the backend. This limits the risk of showing stale data and situations where old data remains in the browser after logout.
XSS protection in dynamic content
Diagrams generated by Mermaid.js run in "strict" mode, which blocks execution of potentially malicious HTML/JavaScript embedded in content. User content is rendered by the framework, not via raw HTML injection.
Transactional emails and API keys
Email delivery is based on Resend. The model is two-tier: a tenant can use their own Resend key, which overrides the global key. API keys are stored on the backend and are never returned to the browser.
Two-factor authentication (2FA)
Every user in your tenant can enable TOTP-based two-factor authentication in account settings. Backup codes are generated for recovery, and administrators can reset a user's MFA if a device is lost. Enforcing 2FA — especially for Admin, Manager, Controller and Finance roles — significantly reduces the risk of account takeover.
GDPR compliance
The platform operates in line with GDPR principles: lawful basis, data minimization, purpose limitation, and user rights (access, rectification, deletion, portability). A Data Processing Agreement (DPA) is available on request. Personally identifiable data stays inside your tenant and is never used to train shared models or exposed to other customers.
Data hosting and location
Application and database run on managed cloud infrastructure hosted in the European Union. Encryption in transit (HTTPS/TLS) is enforced end-to-end between the browser, edge functions and the database. Backend service keys never leave the server side.
Backups and disaster recovery
Beyond the tenant-side Backups module, the underlying managed database performs automated snapshots handled by the infrastructure provider. Combined with your on-demand JSON exports and optional external database, this gives you multiple independent recovery paths.
Audit log
Administrative actions and sensitive operations are recorded in an audit log (admin action logs, security audit trail, invoice audit log). The superadmin console exposes a dedicated Security Audit view where events can be reviewed, filtered and investigated over time.
Data export and right to be forgotten
Tenant administrators can export their data at any time via the Backups module (JSON export). The Danger Zone in settings allows deleting your account and tenant data, which honors the GDPR right to erasure. Deletion is confirmed explicitly to prevent accidental data loss.
What your company can do on top
Security is always a shared responsibility. Below we list the tools and practices we make available in the platform and that are worth turning on in your organization.
Regular backups of your data
The settings panel contains a Backups module. You can perform a manual export of your data to a JSON file and download it locally at any time, as well as configure an automatic backup schedule (daily, weekly, monthly). The history of performed backups is visible in a table and lets you quickly restore a chosen snapshot. We recommend keeping a copy outside the platform as well — e.g. in your company file repository.
Your own external database
For companies that require full control over their data, we provide an External Database module. You can connect your own PostgreSQL, SQL Server or SQLite database (via proxy) and route critical data into your own infrastructure. Configuration and connection testing are available in settings — the module is restricted to the Admin role only, and configuration instructions are provided in several languages.
Account and access hygiene
Create accounts only via invitations (do not share one account across multiple people). Assign roles according to the least-privilege principle — a user who only needs to view statistics should not have the Admin role. Review the active users list regularly and deactivate accounts of people who have left the organization.
Strong passwords and first-password change
Enforce in your organization the use of passwords significantly longer than the system minimum (we recommend 12+ characters, unique to the platform). Do not postpone changing the temporary password — until it is changed, dashboard access is blocked, which is a secure default, but does not replace regular rotation.
Frequently asked questions
Report an incident or vulnerability
If you noticed suspicious platform behavior or a potential security vulnerability, please use the contact form. We handle such reports with priority.
This page is maintained by the costwise.pro team. We describe only mechanisms and features that are actually available on the platform. This is not a certification or an independent audit — it is a description of the current practices and configuration.