Technical Documentation

Security Model

The Open Mandi security model follows a defense-in-depth approach, implementing multiple layers of protection across authentication, data integrity, and financial operations. As an academic platform, the security design balances robustness with transparency.

Authentication

Firebase Authentication — user authentication is handled by Firebase Auth, with Google sign-in as the primary identity provider. The application does not manage or store user passwords directly.
Server-side sessions — upon successful Firebase authentication, the backend issues secure, HTTP-only, same-site session cookies that represent the authenticated user. Session cookies are validated on each request.
Session lifetime — session cookies have bounded lifetimes (5 days) and can be revoked server-side by invalidating the user's Firebase refresh tokens on logout.

Authorization

Resource-based access control — users can only access their own wallets, orders, positions, and transaction history. Ownership is verified on every request.
Public endpoints — order books, recent trades, and transparency data are publicly accessible without authentication.
Write operations — all state-changing operations (deposits, withdrawals, order placement) require authenticated sessions.

Input Validation and Sanitization

Schema validation — all API inputs are validated against strict schemas (using Zod) before processing. Invalid inputs are rejected with descriptive error messages.
Type coercion — numeric inputs are parsed and validated as decimals with defined precision limits.
SQL injection prevention — parameterized queries via ORM; no raw SQL string concatenation.
XSS prevention — React's default output escaping, plus Content Security Policy headers.

Rate Limiting and Abuse Prevention

Per-IP and per-user rate limits on all endpoints (see API Reference for specific limits)
Exponential backoff on failed authentication attempts (account lockout after 10 consecutive failures)
Self-trading prevention in the matching engine (a user's buy cannot match their own sell)

Data Encryption

In transit — all connections use TLS 1.3. HTTP is redirected to HTTPS.
At rest — database encryption enabled at the storage layer. Sensitive fields (email) are encrypted at the application level.

Financial Security

Atomic transactions — all balance changes (order fills, deposits, withdrawals) execute within database transactions. Partial failures result in full rollback.
Balance integrity checks — the sum of all transaction ledger entries for a wallet must equal the current balance. Periodic reconciliation jobs verify this invariant.
Optimistic locking — wallet updates use version checks to prevent race conditions where two concurrent operations could both read the same balance.
Business rule enforcement — deposit limits ($5 max, balance < $1), withdrawal thresholds (balance >= $10), and margin requirements are enforced at both the API layer and the database constraint layer.

Audit Logging

All significant operations generate audit log entries:

Authentication events (login, logout, failed attempts)
Financial operations (deposits, withdrawals, trades)
Order lifecycle events (placement, fill, cancellation)
Position events (open, close, liquidation)
Administrative actions (if applicable)

Audit logs are append-only and include the user ID, IP address, timestamp, action type, and relevant entity IDs. They are retained indefinitely for transparency and research purposes.

Academic Context Considerations

As an academic platform with small financial exposure (max $5 deposits), the threat model differs from production financial systems:

The primary risk is educational data integrity, not large-scale financial theft
Transparency requirements mean some data that would normally be private (aggregate volumes, fee totals) is intentionally public
The security model is documented openly as part of the educational mission