Wolimy pokazać niż powiedzieć „zaufaj nam". Poniżej: co się dzieje, gdy podłączasz bank, kto za co odpowiada, co robimy w kodzie i co sprawdzamy przy każdej zmianie.
Krótka odpowiedź: hasło do banku zostaje w banku, a ClassKasa może tylko czytać konto. Nie przesunie pieniędzy.
Wszystko na tej stronie możemy wskazać palcem. Czego jeszcze nie przetestowaliśmy, tego nie piszemy.
Gdy podłączasz bank
Konto klasy podłącza tylko skarbnik i to funkcja Premium. Rodzice nigdy nie logują się do banku przez ClassKasę.
1
Hasło do banku zostaje w banku
Logujesz się na stronie swojego banku, do której trafiasz przez Enable Banking. ClassKasa nigdy nie widzi ani nie zapisuje Twojego loginu i hasła do banku.
2
Dane pobiera Enable Banking Oy
Enable Banking Oy to dostawca usługi dostępu do informacji o rachunku, zarejestrowany we fińskim nadzorze finansowym (FIN-FSA). Pyta Twój bank o dane, na które pozwalasz, i przekazuje je ClassKasie.
3
Co czytamy: konto, saldo, przelewy
Nazwę, walutę i numer konta, saldo oraz transakcje (kwotę, datę, nadawcę i tytuł). Tylko do odczytu: nic tu nie uruchomi płatności ani nie przesunie pieniędzy.
4
Na jak długo: do 90 dni
Prosimy bank o dostęp na 90 dni, a bank może ustawić krótszy limit. Zaglądamy na konto do czterech razy na dobę. Gdy dostęp zaraz wygaśnie, ClassKasa da Ci znać, żebyś podłączył(a) bank od nowa.
5
Odłączysz w każdej chwili
Dotknij „Odłącz bank" na dole ekranu Bank. ClassKasa przestaje czytać i prosi Enable Banking o zakończenie sesji. Banki zwykle pokazują też w bankowości internetowej listę udzielonych dostępów i tam też możesz go usunąć. Przelewy, które już się wczytały, zostają w klasie, dopóki skarbnik nie usunie historii banku.
ClassKasa stoi na kilku znanych dostawcach. Poniżej to, co każdy z nich mówi o sobie na własnych stronach. To ich oświadczenia, nie nasze.
1
Enable Banking (połączenie z bankiem)
Na swojej stronie pisze, że jest zarejestrowanym dostawcą usługi dostępu do informacji o rachunku, nadzorowanym przez FIN-FSA. Nie znaleźliśmy tam publicznej listy certyfikatów, więc żadnego mu nie przypisujemy.
Te certyfikaty należą do naszych dostawców. Sama ClassKasa nie ma żadnego certyfikatu ISO ani SOC.
Co robimy we własnym kodzie
1
Każdy endpoint ma spisaną regułę
Każdy endpoint, który wysyła lub odbiera dane, ma wpis w tabeli uprawnień, a kod sprawdza go przy każdym żądaniu. Nasz build się wywala, gdy pojawi się nowy endpoint bez wpisu.
2
Cudzych klas dla Ciebie nie ma
Gdy poprosisz o coś z innej klasy, dostajesz „nie znaleziono", czyli tę samą odpowiedź co przy czymś, czego nie ma. Automatyczne testy sprawdzają to celowo.
3
Żadnych numerów kart po naszej stronie
Płatności kartą idą przez Stripe. ClassKasa nigdy nie zapisuje numerów kart.
4
Dostęp do banku tylko do podglądu
Prosimy bank wyłącznie o pokazanie konta, nigdy o wykonanie płatności. Przez ClassKasę nie da się przesunąć pieniędzy.
5
Tylko HTTPS i reguły przeglądarki
ClassKasa każe przeglądarkom zawsze używać HTTPS i nie pozwala wyświetlać się w ramkach cudzych stron.
Co sprawdzamy przy każdej zmianie
Te automatyczne testy idą przy każdej zmianie w kodzie aplikacji. Każdy z nich blokuje build, gdy znajdzie nowy problem.
1
Autoryzowany pentest i ponowny atak
W maju 2026 (wydania v3.27.0 i v3.27.1, oba z 2026-05-29) właściciel przeprowadził autoryzowany pentest ClassKasy z użyciem Claude Code i otwartoźródłowego zestawu pentest-ai-agents. Skończyło się 8 poprawkami, w tym 3 ocenionymi jako High. Potem powtórzyliśmy każdy atak: poprawki wytrzymały, a w 3 kolejnych miejscach z tym samym rodzajem błędu znaleźliśmy i zamknęliśmy dziurę, każdą z testem automatycznym, który najpierw padał, a teraz przechodzi.
Skaner od społeczności OWASP testuje działającą kopię aplikacji przy każdym pull requeście ze zmianami w kodzie i blokuje build przy nowych znaleziskach.
Szuka ryzykownych wzorców w kodzie. Poważne znalezisko blokuje build.
4
Kontrola bibliotek
npm audit blokuje build przy krytycznych lukach w używanych bibliotekach, a OSV-Scanner blokuje go przy nowych znanych lukach.
5
Aktualizacje zależności
Co tydzień Dependabot otwiera zgrupowane pull requesty z aktualizacjami zależności, które znalazł. Aktualizacje łatkowe (patch) i bezpieczeństwa scalają się automatycznie, gdy przejdą wymagane sprawdzenia; duże (major) zawsze czekają na człowieka. Cotygodniowa rutyna zbiera to, co jeszcze otwarte, w jeden pull request i pracuje nad nim, aż przejdą wszystkie blokujące sprawdzenia.
6
Wykrywanie sekretów
Gitleaks przeszukuje całą historię każdego pull requesta pod kątem haseł i kluczy, których nie powinno tam być, a TruffleHog szuka żywych, zweryfikowanych sekretów. Trafienie blokuje build.
7
Testy między klasami
49 automatycznych plików testowych próbuje czytać i zmieniać dane cudzych klas. Za każdym razem musi usłyszeć „nie".
Nic z tego nie jest certyfikatem. Poza pentestem powyżej to automatyczne sprawdzanie.
Znalazł(a)ś coś? Napisz do nas
Napisz na tomek@classkasa.com. Wystarczy krótka wiadomość z krokami do odtworzenia. Prosimy, nie testuj na cudzych klasach. Nasz kontakt jest też w pliku czytelnym dla maszyn, security.txt.