Wir zeigen es dir lieber, statt „Vertrau uns“ zu sagen. Unten: was passiert, wenn du eine Bank verbindest, wer wofür zuständig ist, was wir in unserem Code tun und was bei jeder Änderung geprüft wird.
Die kurze Antwort: Dein Bankpasswort bleibt bei deiner Bank, und ClassKasa kann das Konto nur lesen. Geld bewegen kann es nicht.
Alles auf dieser Seite können wir belegen. Was wir noch nicht getestet haben, schreiben wir nicht.
Wenn du eine Bank verbindest
Nur der Kassenwart der Klasse verbindet ein Klassenkonto, und das ist eine Premium-Funktion. Eltern melden sich über ClassKasa nie bei einer Bank an.
1
Dein Bankpasswort bleibt bei deiner Bank
Du meldest dich auf der eigenen Seite deiner Bank an, die du über Enable Banking erreichst. ClassKasa sieht oder speichert deine Bank-Zugangsdaten und dein Passwort nie.
2
Enable Banking Oy holt die Daten
Enable Banking Oy ist ein Kontoinformationsdienstleister, der bei der finnischen Finanzaufsicht (FIN-FSA) registriert ist. Der Dienst fragt deine Bank nach den Daten, die du erlaubst, und gibt sie an ClassKasa weiter.
3
Was wir lesen: Konto, Kontostand, Umsätze
Kontoname, Währung und Kontonummer, den Kontostand und die Umsätze (Betrag, Datum, Absender und Verwendungszweck). Nur lesend: Damit lässt sich keine Zahlung starten und kein Geld bewegen.
4
Wie lange: bis zu 90 Tage
Wir bitten deine Bank um 90 Tage Zugriff, und deine Bank kann ein kürzeres Limit setzen. Wir schauen bis zu viermal am Tag auf das Konto. Läuft der Zugriff bald ab, sagt ClassKasa dir Bescheid, damit du neu verbinden kannst.
5
Jederzeit trennbar
Tippe unten im Bank-Bildschirm auf „Bank trennen“. ClassKasa hört auf zu lesen und bittet Enable Banking, die Sitzung zu beenden. Banken zeigen die erteilten Zugriffe meist auch im Online-Banking an, dort kannst du sie ebenfalls entfernen. Bereits importierte Überweisungen bleiben in der Klasse, bis der Kassenwart den Bankverlauf löscht.
ClassKasa baut auf einigen bekannten Anbietern auf. Unten steht, was jeder von ihnen auf seinen eigenen Seiten über sich sagt. Das sind deren Aussagen, nicht unsere.
1
Enable Banking (Bankverbindung)
Schreibt auf seiner Website, ein registrierter Kontoinformationsdienstleister unter Aufsicht der FIN-FSA zu sein. Eine öffentliche Zertifikatsliste haben wir dort nicht gefunden, deshalb nennen wir für den Anbieter keines.
Diese Zertifikate gehören unseren Anbietern. ClassKasa selbst hat kein ISO- und kein SOC-Zertifikat.
Was wir im eigenen Code tun
1
Jeder Endpunkt hat eine schriftliche Regel
Jeder Endpunkt, der Daten sendet oder empfängt, hat einen Eintrag in einer Berechtigungstabelle, und der Code prüft ihn bei jeder Anfrage. Unser Build schlägt fehl, wenn ein neuer Endpunkt ohne Eintrag dazukommt.
2
Andere Klassen gibt es für dich nicht
Fragst du nach etwas, das zu einer anderen Klasse gehört, bekommst du „nicht gefunden“, dieselbe Antwort wie bei etwas, das es nicht gibt. Automatische Tests probieren das gezielt aus.
3
Keine Kartennummern bei uns
Kartenzahlungen laufen über Stripe. ClassKasa speichert nie Kartennummern.
4
Der Bankzugriff kann nur ansehen
Wir bitten deine Bank nur, uns das Konto zu zeigen, nie, eine Zahlung auszuführen. Über ClassKasa lässt sich kein Geld bewegen.
5
Nur HTTPS, dazu Browser-Regeln
ClassKasa weist Browser an, immer HTTPS zu verwenden und sich nicht in den Frames anderer Seiten anzeigen zu lassen.
Was bei jeder Änderung geprüft wird
Diese automatischen Prüfungen laufen bei jeder Änderung am Code der App. Jede blockiert den Build, wenn sie ein neues Problem findet.
1
Ein autorisierter Pentest und ein erneuter Angriff
Im Mai 2026 (Releases v3.27.0 und v3.27.1, beide vom 2026-05-29) hat der Inhaber einen autorisierten Pentest von ClassKasa durchgeführt, mit Claude Code und dem Open-Source-Toolkit pentest-ai-agents. Das führte zu 8 Korrekturen, 3 davon mit der Einstufung High. Danach wurde jeder Angriff erneut ausgeführt: Die Korrekturen hielten, und an 3 weiteren Stellen mit derselben Art von Fehler wurde die Lücke gefunden und geschlossen, jeweils mit einem automatischen Test, der zuerst fehlschlug und jetzt besteht.
Ein Scanner aus der OWASP-Community testet bei jedem Pull Request, der Code ändert, eine laufende Kopie der App und blockiert den Build bei neuen Funden.
Sucht nach riskanten Code-Mustern. Ein schwerwiegender Fund blockiert den Build.
4
Prüfung der Bibliotheken
npm audit blockiert den Build bei kritischen Schwachstellen in den Bibliotheken, die wir nutzen, und OSV-Scanner blockiert ihn bei neuen bekannten Schwachstellen.
5
Updates der Abhängigkeiten
Jede Woche öffnet Dependabot gebündelte Pull Requests mit den gefundenen Updates der Abhängigkeiten. Patch-Updates und Sicherheitsupdates werden automatisch zusammengeführt, sobald die erforderlichen Prüfungen bestehen; Major-Updates warten immer auf einen Menschen. Was noch offen ist, fasst eine wöchentliche Routine in einem einzigen Pull Request zusammen und arbeitet daran, bis jede blockierende Prüfung besteht.
6
Suche nach Geheimnissen
Gitleaks prüft den gesamten Verlauf jedes Pull Requests auf Passwörter und Schlüssel, die dort nicht hingehören, und TruffleHog prüft ihn auf aktive, verifizierte Geheimnisse. Ein Treffer blockiert den Build.
7
Tests über Klassengrenzen hinweg
49 automatische Testdateien versuchen, Daten anderer Klassen zu lesen und zu ändern. Sie müssen ein Nein bekommen.
Nichts davon ist ein Zertifikat. Abgesehen vom Pentest oben sind das automatische Prüfungen.
Etwas gefunden? Sag uns Bescheid
Schreib an tomek@classkasa.com. Eine kurze Nachricht mit den Schritten zum Nachstellen reicht völlig. Bitte teste nicht an den Klassen anderer. Unseren Kontakt gibt es auch in einer maschinenlesbaren Datei, security.txt.