No direct database exposure
The browser never connects to MariaDB. A server-side account service validates the session, owns every query, and returns only an allowlisted response.
Account portal boundary
Security is a release gate, not a checkbox.
The public interface is useful now, but real game-account access remains disconnected until authentication, authorization, recovery, auditing, and abuse controls pass review.
01BrowserSession cookie only
→02Account APIAuthentication and policy
→03Read serviceAllowlisted queries
→04Game databasePrivate network only
Account and character scoping
Every lookup derives the account ID from the verified session—not from a browser-supplied account or character ID—and verifies character ownership again.
Layered authentication
Password login is followed by TOTP or passkey support, single-use backup codes, short-lived sessions, device review, and reauthentication for recovery actions.
Safe password recovery
Recovery requires the verified email on file, uses single-use expiring tokens, returns a generic response, and invalidates existing sessions after a successful reset.
Abuse resistance
Login, recovery, ticket, and character-action endpoints require rate limits, CSRF protection, strict origins, structured validation, audit events, and bot controls where risk warrants them.
Read and write separation
Equipment, inventory, missions, and flags use a read-only service identity. Unstuck and return actions enter a separate reviewed command queue with replay protection.
Before live account linking
Required evidence
- Threat model and code review
- Authorization and cross-account isolation tests
- Recovery-token and session-revocation tests
- Rate-limit and abuse testing
- Secret rotation and backup-restore drill
- Independent security assessment before public launch
No connected system can honestly promise zero security risk. KrispyXI reduces that risk through isolation, least privilege, defense in depth, monitoring, and an explicit no-launch-until-verified gate.