Skip to content

7. Rizika

Bezpečnostní rizika

R1 — OTP kód odhalen v response (KRITICKÉ)

Ověřený fakt — z clientAuth/entry.ts: 

return Response.json({ 
  demo_code: contact_type === 'phone' ? code : undefined,
  message: contact_type === 'phone' ? `Demo kód: ${code}` : '...'
});

OTP kód pro přihlášení telefonním číslem je vrácen přímo v HTTP response (nikoliv odesláním SMS). Toto je funkce "demo módu", ale pokud by byl systém nasazen v produkci bez SMS gateway, kdokoliv může přihlásit libovolného klienta bez přístupu k jeho telefonu.

Dopad: Neoprávněný přístup k účtům klientů.

Zmírnění: Před nasazením implementovat SMS gateway, nebo zakázat phone OTP v produkci.

R2 — Automatická tvorba klientů přes OTP (STŘEDNÍ)

Ověřený fakt — z clientAuth/entry.ts: 

if (activeClients.length === 0) {
  const newClient = await base44.asServiceRole.entities.Client.create({
    first_name: 'Nový', last_name: 'Klient', email: contact, ...
  });
}

Kdokoliv s platnou e-mailovou adresou může přes OTP flow vytvořit nového klienta v systému. Neexistuje whitelisting ani schvalování.

Dopad: Zahlcení databáze falešnými klienty, potenciální GDPR implikace.

R3 — Platební odkaz bez autentizace (STŘEDNÍ)

Ověřený fakt — z sendNotification/entry.ts: 

const paymentPath = `/client?payment=1&booking_id=${booking.id}&date=...`;

Platební odkaz je přímé URL s booking_id. Bez dalšího ověření může ten, kdo URL zná, zaplatit za libovolnou rezervaci (nebo vidět její detail).

Odvozeno — může to být záměrné (jednorázový magic link), ale není to dokumentováno.

R4 — Chybí rate limiting na OTP endpointu (STŘEDNÍ)

Ověřený fakt — žádný rate limiting není viditelný v clientAuth/entry.ts. Útočník může generovat neomezené množství OTP kódů pro libovolný e-mail, čímž zahltí Resend API účet nebo obtěžuje uživatele.

R5 — Session klienta v localStorage (NÍZKÉ)

Odvozeno — z ClientAuthContext je patrné, že session klienta je uložena v localStorage. To je zranitelné vůči XSS útokům. Pro citlivý zdravotnický systém by bylo vhodnější HttpOnly cookie.

Ověřený fakt — z sendNotification/entry.ts: 

function generateMeetLink(bookingId) {
  const seed = bookingId.replace(/-/g, '').substring(0, 9);
  // Deterministický algoritmus...
}

Google Meet link je generován deterministicky z booking_id. Pokud někdo zná booking_id, může odvodit meet link. Toto není skutečný Google Meet link — jde o náhodně vygenerovaný URL ve formátu Meet, který nemusí být funkční.

Nezjištěno: Jsou tyto Meet linky funkční? Nebo se počítá s budoucí integrací skutečného Google Meet API?

Technická rizika

R7 — Duplicitní route /PaymentSettingsPage v App.jsx (NÍZKÉ)

Ověřený fakt — řádky 81–82 v App.jsx registrují stejnou cestu dvakrát. Bezprostřední bug.

R8 — N+1 query pattern v některých místech (STŘEDNÍ)

Odvozeno — ze zdrojového kódu clientBooking get_therapists_with_slots je viditelné, že funkce načítá až 1000 bloků a 2000 událostí najednou jako workaround pro N+1 problém. Toto může být pomalé s rostoucím objemem dat.

R9 — NoSQL bez referenční integrity (STŘEDNÍ)

Ověřený fakt — Base44 entity jsou NoSQL. Vztahy jsou udržovány pouze pomocí ID referencí. Při mazání entity (terapeut, místnost) neproběhne kaskádové mazání — zanechá se orphan data.

R10 — Verze SDK se liší mezi funkcemi (NÍZKÉ)

Ověřený fakt — různé funkce importují různé verze SDK:

  • clientAuth/entry.ts: npm:@base44/sdk@0.8.31
  • sendNotification/entry.ts: npm:@base44/sdk@0.8.25
  • clientBooking/entry.ts: npm:@base44/sdk@0.8.31

Nekonzistence může způsobit chyby při aktualizaci.

Procesní rizika migrace

R11 — Vendor lock-in (KRITICKÉ)

Ověřený fakt — veškerá data jsou uložena v Base44 proprietární databázi. Export dat do standardního formátu (SQL, JSON) je možný pouze přes Base44 admin rozhraní nebo SDK — není garantovaný.

Dopad: Při ukončení Base44 platformy nebo přechodu na vlastní backend by migrace dat mohla být problematická.

R12 — Chybí testy (STŘEDNÍ)

Ověřený fakt — v projektu nejsou žádné unit testy, integrační testy ani e2e testy. Migrace bez testů zvyšuje riziko regresí.

R13 — Komplexita business logiky (STŘEDNÍ)

Ověřený fakt — clientBooking/entry.ts obsahuje komplexní logiku:

  • Storno politika s lhůtami a vrácením (credit vs. balíček)
  • Výpočet splatnosti (payment_due_date)
  • Refund flow pro balíček (LIFO pořadí)

Tato logika musí být přesně replikována při migraci.