Security

1. Isolation architecture

The application user is the ownership boundary. Meeting-provider connections, meetings, jobs, recordings, reports and Bitrix24 or Telegram delivery targets carry both user and connection ownership. Database constraints prevent a record from being attached to another tenant.

A Bitrix24 or Telegram identity can be merged with an existing application user only after the same exact provider account and provider user identity is verified through OAuth.

2. OAuth credentials

• Provider passwords are never collected.
• Access and refresh tokens are encrypted at rest using AES-256-GCM.
• OAuth state is random, short-lived, stored only as a hash and consumed once.
• Refresh-token rotation is protected by database leases and optimistic token versions.
• Invalid grants disable only the affected connection.

3. Webhook verification

Meeting-provider webhook signatures and timestamps are verified before processing. URL-validation challenges use the configured secret. Bitrix24 event ownership and application tokens are pinned to the verified portal installation. Unknown or ambiguous events are redacted and quarantined rather than processed.

4. Embedded application sessions

Bitrix24 launch authorization is checked against the configured portal and verified through the Bitrix24 API. Embedded sessions are short-lived, high-entropy and bound to installation, user, dialog and placement. Mutations require a valid origin and cannot substitute a user, connection or target dialog in the request body.

5. Data protection

• Private host URLs are never posted to a shared conversation.
• Public reports use unguessable capability URLs separated from management credentials.
• Local files are isolated by user and provider connection.
• Cloud-recording deletion occurs only after verification of locally saved assets and transcript requirements.
• Provider deauthorization deletes data only for the exact verified connection.

6. Operational practices

The service uses least-privilege scopes, HTTPS, restrictive browser security headers, dependency lockfiles, automated tests, bounded network timeouts, retry limits and health checks. Secrets are provided through deployment secret management and are not committed to the repository.

Security controls are reviewed when adding providers, scopes, webhook types or new data flows.

7. Responsible disclosure