Security — Omnia Model Hub
Security controls are implemented in the application, not promised as a future phase.
Identity separation
Administrators and users have separate account tables, separate sign-in pages, separate session cookies with separate namespaces and separate session lifetimes. Administrator sign-in requires a six-digit authenticator code; prior admin sessions are revoked at each sign-in and sessions are bound to the originating IP.
Application controls
Passwords use scrypt with a per-account salt. Sessions use opaque random tokens stored as hashes. Every state-changing authenticated request requires a per-session CSRF token. Login endpoints have per-account and per-IP failure lockouts; API and gateway endpoints are rate-limited; blocked IPs are rejected before processing.
Data protection
All SQL uses bound parameters with column allow-lists, so a client cannot inject table or column names. Sensitive provider keys are encrypted at rest with authenticated encryption and a file-based master key. API keys are stored as hashes and shown once. JSON responses are rendered with text nodes on the client, and security headers include a restrictive Content Security Policy, frame denial, nosniff and no-store on APIs.
Integrity and audit
Bills, usage events, both credit ledgers, settlements, fee versions, probe records, rating changes, route decisions, security events and audit logs are append-only at the database level through SQLite triggers. Administrator actions record actor, target, before and after values, and IP.
What deployment still adds
Production deployment should add TLS termination at a reverse proxy, host firewall, encrypted backups, secret rotation, log shipping and a Web Application Firewall. These are infrastructure tasks, not missing application features.