Haki Technology Institute
Die Lernmodule am Institut führen Schritt für Schritt durch Code, Architektur und die Sicherheitsfragen, die dabei auftauchen. Erst ein sauberer Login-Flow, dann die Datenbankabfrage, dann der Blick auf das, was ein Angreifer daraus machen könnte.
Module und Lernpfade ansehen
Das Haki Technology Institute ist eine Bildungseinrichtung, keine Agentur und kein Dienstleister. Wir arbeiten mit Entwicklerinnen im ersten Berufsjahr, mit Quereinsteigern aus der IT-Administration und mit Teams, die ihre internen Abläufe technisch sauber aufstellen möchten. Was uns interessiert, ist die Frage hinter dem Code: warum eine Anmeldung so aufgebaut ist, wie sie ist, und wo sie unter Last bricht.
Unsere Module richten sich an Leute, die bereits erste Zeilen geschrieben haben und jetzt verstehen wollen, was unter der Oberfläche passiert. Wir setzen kein Vorwissen in Kryptografie voraus, erwarten aber Bereitschaft, Dokumentation zu lesen und Fehler selbst nachzustellen. Wer nur eine Zertifizierung sucht, wird bei uns nicht glücklich.
Jedes Thema beginnt mit einem kurzen Konzepttext, gefolgt von einer Aufgabe an einem echten Repository. Danach kommt der unangenehme Teil: Wir schauen gemeinsam, wo der eigene Ansatz scheitert. Das kann ein fehlender Rate-Limit sein, eine offene Debug-Route oder ein Token, das zu lange gültig bleibt. Aus diesen Befunden entstehen die nächsten Übungen.
Wir verkaufen keine Zertifikate, die Türen öffnen sollen, und keine Werkzeuge, die Probleme über Nacht lösen. Auch fertige Copy-Paste-Lösungen für Angriffe gehören nicht zu unserem Material. Stattdessen arbeiten wir mit Ausschnitten aus realen Audit-Berichten, mit Pull-Request-Diskussionen und mit Fehlkonfigurationen, die in kleinen Teams tatsächlich vorkommen.
Wir schreiben in ganzen Sätzen, nennen Werkzeuge beim Namen und sagen, wenn eine Methode für ein kleines Team zu aufwendig ist. Wer eine Empfehlung von uns bekommt, soll sie begründen können, ohne auf Folien zurückzugreifen. Diese Haltung zieht sich durch die Kursunterlagen, die Blogbeiträge und die Rückmeldungen, die wir zu eingereichten Lösungen geben.
Die Beiträge unten greifen genau die Stellen auf, an denen in unseren Modulen die meisten Rückfragen kommen: Anmeldung, Risikoanalyse, Zusammenarbeit im Team. Kein Ersatz für die Kursarbeit, eher eine zweite Perspektive mit Code und Beispielen.
Alle Artikel entstehen aus dem laufenden Unterricht und werden überarbeitet, sobald sich Werkzeuge oder Empfehlungen ändern.
Passwort-Hashing mit bcrypt oder Argon2, Session-Cookies, Token-Rotation und Fehlermeldungen, die nichts verraten. Der Beitrag geht die Bausteine in der Reihenfolge durch, in der sie im Projekt auftauchen, und zeigt an Node.js- und Python-Beispielen, wo Rate-Limiting und CSRF-Schutz eingehängt werden.
Beitrag öffnen
Vier Schritte, die sich in einem halben Workshoptag erledigen lassen: Datenflüsse skizzieren, Vertrauensgrenzen markieren, STRIDE durchgehen, Maßnahmen priorisieren. Beispiele aus einem Buchungssystem und einer API-Schnittstelle, dazu der Weg von der Notiz ins Ticket.
Beitrag öffnen
Prüfpunkte jenseits von Formatierung: Umgang mit Benutzereingaben, Fehlerbehandlung bei externen Aufrufen, Rechteprüfung an jeder Endpunktgrenze, keine Zugangsdaten im Repository. Drei Pull-Request-Ausschnitte zeigen, wie ein Kommentar formuliert wird, der das Problem benennt und eine Alternative vorschlägt.
Beitrag öffnenDie Lernreihen sind so aufgebaut, dass nach jeder Einheit etwas Konkretes im Projektordner liegt: eine funktionierende Funktion, ein überarbeiteter Pull Request, ein dokumentierter Angriffsvektor. Kein reines Zuhören, sondern Arbeit an echten Aufgabenstellungen.
Nach dieser Einheit steht ein vollständiger Login-Flow mit Passwort-Hashing, Session-Cookies und Rate-Limiting im eigenen Repository. Die Teilnehmenden prüfen den Ablauf gegen eine Checkliste und beheben die gefundenen Schwachstellen direkt im Code.
Die Teilnehmenden skizzieren Datenflüsse eines Beispielsystems, markieren Vertrauensgrenzen und leiten daraus priorisierte Maßnahmen ab. Ergebnis ist ein ausgefülltes Modell, das sich als Ticketvorlage in den nächsten Sprint übernehmen lässt.
An drei Pull-Request-Ausschnitten wird geübt, Eingabevalidierung, Fehlerbehandlung und Rechteprüfung zu kommentieren. Am Ende liegt eine eigene Review-Checkliste vor, die im Team ohne zusätzlichen Aufwand gepflegt werden kann.
Die Teilnehmenden zerlegen ein bestehendes System in Module, definieren Schnittstellen und dokumentieren Abhängigkeiten. Das Ergebnis ist ein Architekturbild, das neue Teammitglieder ohne lange Einarbeitung verstehen.
Es entsteht ein Testplan mit Unit-, Integrations- und End-to-End-Tests für ein Beispielprojekt. Die Teilnehmenden richten die Testläufe lokal ein und sehen, welche Fehler die einzelnen Stufen tatsächlich abfangen.
Die Teilnehmenden erstellen eine technische Dokumentation mit Aufbau, Betrieb und bekannten Grenzen des Systems. Das Ergebnis dient als Nachschlagewerk für Betrieb und Übergabe an neue Kolleginnen und Kollegen.
Alle Module lassen sich einzeln belegen. Wer eine vollständige Reihe durchläuft, arbeitet am Ende an einem zusammenhängenden Projekt statt an isolierten Übungen.