Security in Butiga is not one label or promise. Access starts with an authenticated session, followed by checks of the active user, workspace membership, role and right to the specific record. Workspace data is also separated by PostgreSQL rules. Email secrets are encrypted, attachments are not public links, and important sensitive actions leave an audit trail. A backup is considered usable only after a controlled restore test.
What each layer protects
- Sign-in and session
Verify the user's identity and end access when the session expires, is revoked or the user is no longer active. - Membership and role
Determine which workspace and business actions a user may access. - Specific record checks
Restrict access to a lead, quote, attachment or other object by role, ownership and context. - Database isolation
PostgreSQL Row-Level Security applies the workspace context when an application query reaches the database. - Secret encryption
Protects email passwords and OAuth tokens from being stored as readable text. - Audit and recovery
Help investigate sensitive changes and restore data through a controlled procedure.
Sign-in, passwords and session management
Passwords are not stored in readable form. The system stores cryptographic hashes and checks entered passwords without allowing administrators to read the original. Successful sign-in creates a server session with a random secret token; the database stores only that token's hash.
The web session cookie is HTTP-only, uses secure mode in production and has SameSite protection. Sessions have time and inactivity limits. Signing out revokes the active session. Changing or successfully resetting a password revokes the user's other active sessions, and an administrator can review and revoke sessions when necessary.
Browser requests that change data use CSRF checks. Sign-in attempts and sensitive operations such as email connections are rate-limited. Private application responses prohibit caching, while security headers reduce exposure of unnecessary browser information.
Production boundary check
The check on 29.07.2026 confirmed an HTTPS application response, an HSTS header, no caching of private responses, noindex protection for the internal application and a 401 response from a private CRM route without authentication. This verifies the publicly visible boundary, but does not replace a penetration test.
Workspace separation and role control
A user cannot access a workspace simply by knowing or sending its identifier. The backend checks that the workspace exists, is active and that the user has active membership. The selected workspace becomes the server-side context for subsequent queries; client data from a form or URL is not a source of authorisation.
Platform administration is separate from ordinary workspace routes. Normal business routes must not silently read every company's data, even when a user has broader platform rights.
| Control | Business outcome |
|---|---|
| Active membership | Users enter only workspaces to which they are actually assigned. |
| Backend role | Administration, sales, management and onboarding have different action scopes. |
| Record access | Sales or operational users do not automatically receive every lead, quote or attachment. |
| Row-Level Security | A query without the correct workspace context does not return another company's data. |
| Isolation tests | Guessing another user's identifier and cross-workspace changes are tested as negative scenarios. |
Why both application and database checks exist
Roles and ownership are best understood in the application, while the database sees the final workspace context. Using both levels reduces the chance that one missing check in a new route immediately exposes another company's data. The runtime database account cannot bypass the enforced RLS rules.
Illustrative example: opening a record from another workspace
- A signed-in user sends a request with another workspace's identifier or someone else's record identifier.
- The backend requires active membership in the selected workspace. Without it, the request stops.
- If the route reaches the database, the query uses the server-established workspace context.
- The RLS rule does not return a row belonging to another workspace.
- Sensitive actions also require role and specific business-record access checks.
This example describes the actual checking architecture. It does not claim that any system is impossible to misconfigure.
Business email and credentials
Butiga uses Google OAuth for Gmail connections. The application does not request or store your Google password. Production code requests the Gmail permission needed for a user email client: reading selected messages, synchronisation, sending messages composed by the user and changing message state. The OAuth refresh token is encrypted on the backend and tied to the relevant workspace and email account.
For standard IMAP/SMTP connections, the access secret is encrypted before storage. The cryptographic context includes the workspace, email account and secret purpose, so the value is not treated as freely transferable text between accounts. Google or email access can be disconnected when no longer needed.
Message HTML is stripped of active elements such as scripts, forms and iframe content before display. This reduces the risk of executing active email content, but users should still handle links and attachments from unknown senders with care.
Google verification status: we do not present Google OAuth verification as complete until Google concludes its process. Production code and public documentation remain limited to user email-client functions; Gmail data is not used for advertising or general model training.
Attachments and business documents
Attachments are not exposed through permanent public URLs. Listing, uploading, downloading and deleting require authentication, an active workspace and access to the linked lead. Upload size is limited, filenames are sanitised for display and download, and attachments must remain linked to the appropriate lead, quote or onboarding record.
Attachment downloads and deletions are recorded in the audit trail. Not every team member may delete attachments: roles, the uploader, lead owner or onboarding owner are checked.
Controlled room for public quote review
Buyer Room uses an unpredictable, time-limited link tied to one quote and its current version. The link can be revoked or replaced, and a version change invalidates previous access. Public responses prohibit indexing and caching, rate-limit requests and do not grant access to the rest of the workspace.
The link recipient can see that quote and its attachments while the room is active. Send links only to intended recipients; do not publish or forward them without authorisation. A view is recorded as a sales signal, while acceptance or rejection requires separate confirmation of the recipient's name and email address.
Audit trails, requests and regression checks
Butiga records important sensitive changes, including sign-in events, password resets, session revocation, membership changes, attachment access and key business-record changes. Audit records contain the business context needed for later review. We do not claim that the audit records every click or is inherently immutable.
API requests receive an identifier that helps connect an error to a server record without relying solely on the user's description. Regression tests discover mounted API routes and check that new routes do not become anonymously accessible without an explicit decision. Dedicated tests cover roles, tenant isolation and attempts to access other users' identifiers.
Backup, restore and recovery
The documented procedure requires a database backup before production migrations, a non-empty file check and a checksum. Operational tables and audit records are included in the database backup; attachment storage is protected separately when local uploads are used.
A backup is not verified merely because a file exists. Restoration is performed into a separate temporary database, followed by migration and tenant-isolation checks; the test database is then removed. The last recorded restore test, on 21.07.2026, confirmed complete restoration and fail-closed tenant-data behaviour in a controlled environment.
Only authorised server administrators may restore production. Restore events must also be recorded outside the application because restoring a database can revert its audit trail. Retention periods, RPO, RTO and contractual availability are defined by plan and contract; we do not state unapproved universal values.
Protection in the Android app
The Android app rejects unencrypted network traffic to production services. Access tokens and local business payloads are encrypted using a key generated by Android Keystore on the device. The key is not stored as an ordinary application setting.
Device protection remains a shared responsibility. Users should enable screen locking, update Android regularly and immediately report lost or compromised devices so sessions can be revoked. Butiga does not currently describe biometrics as mandatory on every supported device.
What Temelj za rast does and what your team does
| Temelj za rast | Customer organisation |
|---|---|
| Maintains authentication, server-side checks, workspace isolation and product security updates. | Assigns accounts only to people needing access and removes it when someone changes role or leaves the team. |
| Protects email secrets in supported workflows and restricts attachment access. | Uses separate accounts and strong passwords, and disconnects mailboxes or devices no longer needed. |
| Audits selected sensitive events and documents backup/restore procedures. | Avoids unnecessary sensitive personal data and defines a lawful purpose, retention period and internal processing rules. |
| Receives and investigates reports of possible security issues. | Promptly reports suspicious activity, lost devices or incorrectly assigned permissions. |
What we deliberately do not claim
- No absolute security
No SaaS system is impenetrable. Controls reduce risk and limit consequences, but cannot eliminate every possible incident. - No invented certification
We do not present Butiga as ISO 27001, SOC 2 or bank-grade without a completed independent process and current evidence. - MFA and SSO are not promised
The currently verified baseline uses passwords, server sessions and access controls. We do not list MFA or SSO as available before implementation and verification. - No universal SLA
RPO, RTO, retention, dedicated infrastructure and SLA are confirmed in the specific plan and contract.
Responsible reporting of possible issues
If you think you have found a security vulnerability, email contact@temelj.me with the subject “Security report — Butiga”. Include the affected feature, time checked, reproduction steps and expected versus actual results. Use demonstration data and remove passwords, tokens, email content and personal data from attachments.
Do not access others' data, download data as proof, change or delete records, retain access or conduct denial-of-service, social engineering or physical-access tests. Stop once minimal evidence is confirmed and allow reasonable investigation time before public disclosure. We do not currently promise a monetary reward or fixed response time.
Privacy and the next step
Product security and lawful data processing are different responsibilities. Read the privacy notice, terms of use and cookie policy. For questions about your workspace architecture, migration, processor role or contractual controls, contact Temelj za rast. For a demonstration of permissions, email connections and Android use, you can book a demo.