Security Operations: Hardening the iGaming Edge
The difference between a toy demo and a credible reference architecture is how it handles abuse. We identified five critical threat vectors for a high-concurrency betting platform and engineered defences for each.
Threat Modelling
Section titled “Threat Modelling”1. Double-Spend (Race Condition)
Section titled “1. Double-Spend (Race Condition)”Threat: Two concurrent bet requests exploit write contention to debit a user’s balance twice.
Defence: Durable Objects guarantee single-writer consistency. The BettingLedger processes requests sequentially—there is no interleaving, no lock contention, and no race condition. The two-phase commit (authorise → confirm) with a 30-second hold TTL ensures that incomplete transactions are automatically rolled back.
2. Replay Attack
Section titled “2. Replay Attack”Threat: An attacker re-submits a valid bet request to trigger a duplicate debit.
Defence: Every request carries a unique request_id. The Durable Object caches the result of each successful operation for 24 hours. If a replay is detected, the DO returns the cached response without re-processing the transaction.
3. Hold Exploitation (Balance Lock-in)
Section titled “3. Hold Exploitation (Balance Lock-in)”Threat: A malicious user creates holds without confirming them, permanently locking their (or others’) balance. Defence: Maximum 1 active hold per user. All holds carry a 30-second TTL enforced by a DO alarm. If confirmation doesn’t arrive, the alarm triggers an automatic rollback. No manual intervention required.
4. DDoS / Resource Exhaustion
Section titled “4. DDoS / Resource Exhaustion”Threat: High-volume automated requests causing budget overruns or service degradation. Defence: Multi-layer protection: Cloudflare WAF at the edge, per-IP rate limits (5 login attempts/min, 200 allocations/min), and a Global Governor (singleton Durable Object) that monitors aggregate request rates and triggers a “lockdown” mode if traffic exceeds safety limits.
5. Injection (SQLi/XSS)
Section titled “5. Injection (SQLi/XSS)”Threat: Malformed payloads targeting the D1 compliance database or the frontend.
Defence: All API inputs are validated against Zod schemas before processing. All D1 queries use parameterised prepare().bind() statements. No raw SQL. The CSP header restricts script execution to trusted origins.
Geo-Fencing & Jurisdiction
Section titled “Geo-Fencing & Jurisdiction”iGaming is jurisdiction-locked. Using request.cf.country, we block or redirect users from unauthorised regions before the request reaches application logic. This is a sub-millisecond operation at the edge—no origin round-trip required.
PoC Limitations & Production Hardening
Section titled “PoC Limitations & Production Hardening”This is a proof-of-concept. Several design decisions were made for speed that would need to be hardened for production:
- Authentication: The PoC uses simplified JWT with
httpOnlycookies. Production would require full OAuth2/OIDC integration with an enterprise IdP (Okta, Azure AD), with enforced MFA. - Encryption: The PoC relies on platform-managed TLS 1.3 and AES-256 at rest (Cloudflare-managed). Production may require application-layer encryption for PCI-DSS compliance.
- Audit Retention: D1 audit logs are purged after 48 hours in the PoC. Production would export to cold storage (BigQuery, S3) for long-term compliance.