Przegląd techniczny platformy „Klient A"

K-1. Realizacja zamówienia zależy od powrotu użytkownika do aplikacji

Zamówienie zmienia status na opłacone w handlerze strony powrotu (/checkout/success), po odczytaniu identyfikatora sesji Stripe z adresu. Webhook checkout.session.completed istnieje, ale zapisuje wyłącznie log — nie zmienia stanu zamówienia. Handler nie sprawdza też, czy dane zdarzenie było już przetwarzane.

Dwa niezależne scenariusze:

• Klient płaci, ale nie wraca (zamyka kartę, traci zasięg, bank przekierowuje po 3D Secure z opóźnieniem) — pieniądze pobrane, zamówienie w stanie „oczekuje", klient pisze reklamację. Przy obecnym wolumenie to pojedyncze przypadki miesięcznie; po dziesięciokrotnym wzroście ruchu to codzienna obsługa ręczna.
• Stripe dostarcza zdarzenie dwukrotnie — co jest normalnym, udokumentowanym zachowaniem przy ponowieniach. Gdy webhook zacznie realizować zamówienia bez klucza idempotencyjnego, powstaną duplikaty.

// app/checkout/success/page.tsx  (fragment, zanonimizowany)
const session = await stripe.checkout.sessions.retrieve(searchParams.session_id)
if (session.payment_status === 'paid') {
  await db.order.update({ where: { id: session.metadata.orderId },
                          data: { status: 'PAID' } })   // ← jedyne miejsce zmiany statusu
}

// app/api/webhooks/stripe/route.ts  (fragment)
case 'checkout.session.completed':
  logger.info('checkout completed', { id: event.id })   // ← brak zmiany stanu
  break

1. Przenieść zmianę stanu zamówienia do webhooka; strona powrotu ma tylko pokazywać wynik.
2. Dodać tabelę processed_events z event.id jako kluczem głównym i przetwarzać zdarzenie w transakcji z zapisem tego identyfikatora — powtórka nie zrobi wtedy nic.
3. Weryfikować podpis stripe-signature (obecnie weryfikowany poprawnie — to zostaje bez zmian).
4. Dodać zadanie okresowe wychwytujące zamówienia opłacone w Stripe, a niezrealizowane u Państwa — jako siatka bezpieczeństwa.

K-2. Izolacja danych między kontami egzekwowana w interfejsie, nie w zapytaniach

Zapytania do bazy w kilku endpointach pobierają rekord po jego identyfikatorze, a przynależność do konta sprawdzana jest dopiero przy renderowaniu widoku. W trzech miejscach (eksport danych, pobranie faktury, szczegóły zamówienia) tej weryfikacji nie ma wcale — wystarczy podmienić identyfikator w adresie.

To najprostsza do wykorzystania klasa podatności: nie wymaga narzędzi, wystarczy zmiana cyfry w URL. Przy danych klientów i fakturach oznacza ryzyko naruszenia ochrony danych osobowych ze wszystkimi tego konsekwencjami, łącznie z obowiązkiem zgłoszenia.

// app/api/invoices/[id]/route.ts  (fragment, zanonimizowany)
const invoice = await db.invoice.findUnique({ where: { id: params.id } })
return Response.json(invoice)        // ← brak filtra po organizationId

Sprawdzone wyłącznie przez lekturę kodu; zgodnie z ustaleniami nie wykonywałem żadnych zapytań do środowiska produkcyjnego.

1. Wprowadzić jedną warstwę dostępu do danych, w której każde zapytanie obowiązkowo przyjmuje kontekst konta — tak, by pominięcie filtra było błędem kompilacji, a nie przeoczeniem.
2. Rozważyć Row Level Security w PostgreSQL jako drugą linię obrony niezależną od kodu aplikacji.
3. Dopisać testy, które próbują pobrać cudzy zasób i oczekują odpowiedzi 404 — to tanie i wychwytuje regresje.