securebit-chat/SECURITY.md

Security Policy

Supported release line

Release	Status	Protocol
v4.1.x	Supported	4.1
earlier releases	Unsupported	legacy

Users should run the current supported release line to receive the latest verification, storage, and file-transfer protections.

Reporting a vulnerability

Please report security issues privately before public disclosure.

• Email: SecureBitChat@proton.me
• Include: affected version, reproduction steps, impact, and any proof-of-concept material
• Avoid publishing exploit details before a coordinated fix is available

Current security behavior

Peer verification

• SAS verification is mandatory and interactive.
• SAS values are derived deterministically from shared session material.
• Users must compare the code out of band and enter the matching code manually.
• A session becomes verified only after both local and remote confirmations succeed.
• Three failed local SAS entries terminate the session.
• Protocol version 4.1 rejects incompatible peers instead of silently falling back to older verification behavior.

Message handling

• Chat payloads remain encrypted in transit.
• Decrypted incoming chat text is sanitized before it reaches React state or the UI.
• Encrypted payload validation remains separate from display sanitization.

File transfer

• Incoming transfer metadata is validated before presentation to the user.
• Every incoming file requires explicit Accept or Reject consent.
• Receive buffers are not allocated before consent.
• File names are normalized for display and dangerous names are rejected.
• Allowed file types are explicit and validated using both MIME type and extension.
• High-risk executable or scriptable types are blocked.
• Repeated incoming transfer offers are rate-limited and bounded.

Local storage

• Sensitive IndexedDB metadata is encrypted, including timestamps and session-related fields where feasible.
• Only minimum lookup keys remain in plaintext when required.
• Legacy plaintext metadata is migrated lazily on read.
• Corrupted encrypted metadata fails closed.

Network privacy

• Default mode preserves standard WebRTC connectivity.
• Relay-only privacy mode uses TURN by setting iceTransportPolicy: "relay".
• STUN-only configurations do not provide IP protection.
• If TURN is absent, the UI warns that direct WebRTC may expose IP addresses.

Lifecycle cleanup

• Disconnect cleanup closes data channels and peer connections, clears verification state, and wipes session crypto state.
• Timers, deferred retries, decoy traffic, pending transfers, and React file-transfer callbacks are cleaned up on shutdown.
• Received file buffers are retained only within a bounded window and expired handles fail gracefully.

Security verification commands

npm audit
npm test
npm run build

Limitations

• A compromised endpoint can still expose plaintext.
• WebRTC privacy depends on deployment configuration; TURN must be supplied by the operator.
• Users must perform the out-of-band SAS comparison correctly.
• Browser security and operating-system security remain part of the threat model.