Security Audit & Remediation
July 2026 · Completed — all confirmed issues fixed, tested and deployed
На кратко (БГ)
Извършихме пълен одит по сигурността на GembaKitchen и отстранихме всички открити уязвимости.
Одитът покри цялата платформа: вход и двуфакторна автентикация, смяна на парола и изтриване на профил, изолация между отделните ресторанти, ваучер/отстъпка/подарък кодове, абонаменти и таксуване, известия, owner конзолата, вход с портфейл (web3), валидация на входа и сигурност на инфраструктурата. Комбинирахме автоматичен анализ, няколко независими проверяващи агента и реални, недеструктивни тестове за проникване срещу production средата, като всяка находка беше независимо потвърдена преди поправка.
Резултат: 9 потвърдени находки (1 критична, 2 високи, 1 средна, 5 ниски) — всичките отстранени. Проверени като здрави без нужда от промени: изолацията между ресторантите, хеширането и еднократната употреба на кодовете, подписаната webhook верига, защитата срещу инжекции и криптографските примитиви.
Summary (EN)
GembaKitchen completed a comprehensive, multi-agent security audit and every confirmed issue has been fixed, tested and deployed.
The audit covered the whole platform — authentication & two-factor login, password change and account deletion, multi-tenant data isolation, voucher/discount/gift codes, subscriptions & billing, in-app notifications, the owner console, wallet (web3) login, input validation, dependencies and infrastructure hardening. It combined automated static analysis, dependency scanning, several independent review agents and live, non-destructive attack testing against the production API, with every finding independently re-verified before a fix was written.
Findings & fixes
| Area | Severity | Status |
|---|---|---|
| Email-verification session handling | Critical | Fixed |
| Two-factor login binding | High | Fixed |
| Login / verification rate limiting | High | Fixed |
| First-cycle subscription accounting | Medium | Fixed |
| Discount-code accounting | Low | Fixed |
| Session invalidation after credential change | Low | Fixed |
| Contact-form input sanitisation | Low | Fixed |
| Wallet-challenge housekeeping | Low | Fixed |
| HTTP security headers | Low | Fixed |
1 · Email-verification session handling — Critical
An edge case in the "confirm your e-mail" step could return a session for an already-verified account without a password or second factor. Fixed: it now returns a status only and always routes through the normal password + 2FA sign-in.
2 · Two-factor login binding — High
The second-factor step is now cryptographically bound to a successful password step, so a one-time code can never be used on its own to obtain a session.
3 · Login / verification rate limiting — High
Strict per-client rate limiting was added to all sign-in, two-factor, e-mail-code, password-change, account-deletion and wallet-challenge endpoints, preventing automated guessing of any code.
4 · First-cycle subscription accounting — Medium
A new subscription's first billing cycle could be counted twice internally. Fixed so the paid period and revenue are recorded exactly once. No customer was over- or under-charged — this was an internal-accounting fix.
5 · Discount-code accounting — Low
A discount code is now validated and consumed only after the target plan is confirmed, so an invalid request can no longer consume a shared promotional code.
6 · Session invalidation after credential change — Low
Changing your password or disabling two-factor now immediately invalidates previously issued sessions, so an old token cannot remain valid after you secure your account.
7 · Contact-form input sanitisation — Low
The sender name on the public contact form is now sanitised to prevent any markup injection into the internal notification e-mail.
8 · Wallet-challenge housekeeping — Low
The wallet-login challenge endpoint now cleans up expired/used challenges and is rate-limited, preventing unbounded growth.
9 · HTTP security headers — Low
Standard hardening headers were added across the API and the server version banner was removed.
Verification
Every fix was exercised with a dedicated test — auth-bypass attempts returning the correct rejections, rate limits engaging, session revocation on credential change, correct single-count billing, discount codes preserved on invalid requests — and confirmed non-breaking against normal application behaviour before deployment.