Security Model

Overall security architecture and practices in TMA Cloud.

Authentication Security

Password Security

• Hashing: bcrypt, 10 rounds
• Storage: Hashed passwords only but a Google-only account stores no password at all
• Validation: 8–128 characters, enforced by the server and mirrored in the client

Token Security

• JWT Tokens: Signed and verified
• httpOnly Cookies: Prevents XSS attacks
• Expiration: Automatic token expiration
• Versioning: Token revocation support

Session Security

• Active Session Management: View device, current reported IP, heartbeat-based online status, and revoke sessions
• Logout All: Invalidate all tokens
• Idle Expiry: Sessions end after an inactivity window (30 days by default)
• CSRF: State-changing requests must carry X-Requested-With: XMLHttpRequest, Checkout API Overview

Authorization Security

Access Control

• Account Isolation: A login can only reach its own account's files
• Role-Based: Admin vs regular user permissions
• Per-Permission Grants: Sub-users hold an explicit set of permissions; anything not granted is refused
• API Authorization: Endpoint-level checks, run before request bodies are read
• Share Link Security: Token-based access

Input Validation

Routes validate accepted fields with express-validator schemas or controller-specific checks.

• Type and format checks: Request fields have type, length, and format limits where required
• Database queries: Values are passed through parameterized queries
• File paths: Storage keys reject separators and traversal sequences
• MIME types: Stored types come from file content (magic bytes), not client headers

Data Security

File Storage

• User Isolation: Files stored per-user
• Path Validation: Prevents directory traversal
• Access Control: Database-level checks
• MIME Type Detection: Stored type is detected from content (magic bytes), not the filename; a content/extension mismatch is never used to reject an upload
• Safe Serving: Downloads use Content-Disposition: attachment and X-Content-Type-Options: nosniff, so a disguised file downloads instead of running in the browser

File Encryption

• Algorithm: AES-256-GCM in Google Tink's AES-GCM-HKDF-STREAMING format (AES256_GCM_HKDF_1MB)
• Segmented: Objects are split into 1 MB segments, each authenticated on its own. This lets downloads serve HTTP Range requests without reading the whole file
• Envelope keys: Each newly encrypted object version receives a random data key (DEK); FILE_ENCRYPTION_KEY is the key-encryption key (KEK) that wraps it. A server-side logical copy reuses unchanged ciphertext and its wrapped DEK. Rotating the KEK rewraps stored DEKs without re-encrypting objects
• Scope: Stored file contents in the S3-compatible bucket. File names and metadata live in the database
• Key Management: Environment variable configuration
• Stream Processing: Files are processed in segments instead of being buffered in full
• Automatic: Encryption on upload, decryption on download

Database Security

• Parameterized Queries: SQL injection prevention
• Connection Security: SSL support
• Credential Protection: Environment variables

Network Security

HTTPS

• Recommended: Use HTTPS in production
• Cookie Security: Secure flag for cookies
• Headers: Security headers configured
• S3: Bucket policy can enforce HTTPS-only access; run npm run s3:policy-https or npm run s3:protect-all from backend (see Storage Management).

Rate Limiting

The API employs rate limiting to prevent abuse and ensure service stability. Different limits are applied to authentication, file uploads, and general API endpoints. For detailed information, see the Rate Limits reference.

Forwarded Client IPs

The backend ignores forwarded client IP headers unless the connecting reverse proxy is listed under Settings → Administration → Known Proxies. This prevents a direct client from supplying its own X-Forwarded-For value.

Desktop app only access (optional)

• Admins can place an instance into a mode where the backend requires a custom HTTP header that only the Electron desktop app sends
• The middleware checks this header for all main app routes and blocks requests that do not include it
• Share links (/s/*), /health, and /metrics remain reachable without the header
• This setting is an access policy, not client attestation. A client that reproduces the header can pass the check, so authentication and authorization remain required

Audit & Logging

Audit Trail

• Recorded events: Authentication, file, sharing, document, admin, and account actions
• Queue: pg-boss stores events until the worker writes them
• Retention: Rows older than 30 days are removed by the scheduled cleanup job
• Queries: The audit_log table and audit_activity view expose stored events

Logging Security

• Secret Masking: Automatic redaction
• Structured Logs: JSON format for analysis
• Request Tracking: Request ID propagation
• Error Logging: Detailed error information

Security Headers

• CSP: Content Security Policy
• X-Frame-Options: Prevent clickjacking
• X-Content-Type-Options: MIME type sniffing prevention
• X-XSS-Protection: XSS protection
• Referrer-Policy: Referrer information control
• Permissions-Policy: Feature permissions

Best Practices

For Administrators

• Use strong passwords
• Enable MFA
• Regularly review audit logs
• Keep software updated
• Use HTTPS in production

For Users

• Use strong passwords
• Enable MFA for additional security
• Review active sessions regularly
• Be cautious with share links

Related Topics

• Authentication - Authentication system
• Authorization - Access control
• Audit Logs - Audit system
• Security Features - Error handling