Die meisten Sicherheitslücken entstehen nicht beim Angriff – sie entstehen beim Entwurf: fehlende Rechteprüfung, ungeprüfte Eingaben, Secrets im Repository.
Deshalb behandle ich Security als Teil des Designs, nicht als Nachgedanken – von der Vertrauensgrenze im Architekturbild bis zur Verschlüsselung sensibler Daten im Code.
Sicherheit ist kein Produkt, das man dazukauft – sie steckt in Entscheidungen, die in jedem Projekt anfallen:
Broken Access Control, Injection, Security Misconfiguration, unsichere Deserialisierung – die bekannten Schwachstellenklassen sind für mich keine Checkliste am Ende, sondern Entwurfsfragen am Anfang: Wo verläuft die Vertrauensgrenze? Welche Daten kommen von außen? Wer prüft wo die Berechtigung?
Jede Eingabe ist erst einmal feindlich – aus Formularen, APIs, Dateien und Importen genauso wie aus "internen" Systemen. Validierung gehört an die Vertrauensgrenze (serverseitig, nicht nur im Client), mit Whitelist-Regeln, typisierten Parametern und Ausgabe-Encoding gegen Injection und XSS.
Wer ist der Nutzer – und was darf er wirklich? Ich entwerfe Login-, Token- und Session-Konzepte auf Basis etablierter Standards (OAuth2/OIDC statt Eigenbau) und trenne sauber zwischen Authentifizierung und Autorisierung: Rollen- und Rechteprüfung serverseitig, an jedem Zugriffspunkt, testbar – nicht nur im Menü ausgeblendet.
Kryptographie einsetzen heißt vor allem: nichts selbst erfinden. Bewährte Verfahren und Bibliotheken, Transportverschlüsselung konsequent, Verschlüsselung ruhender Daten dort, wo Datenschutz oder Regulatorik es verlangen – und ein Schlüssel-Handling, das den Verlust eines Geräts oder Backups von Anfang an einkalkuliert.
Passwörter, API-Keys und Zertifikate gehören nicht in Code, Konfigurationsdateien oder Logs. Meine Regel: Platzhalter ohne Default in jeder Umgebung, Werte ausschließlich aus der Umgebung bzw. einem Secret-Store – und wenn ein Secret je im Repository lag, wird es rotiert, nicht nur gelöscht.
APIs sind die Außenhaut Ihrer Anwendung: objektbezogene Berechtigungsprüfung gegen IDOR/BOLA, strikte Schemas statt Mass Assignment, Rate-Limiting, nachvollziehbares Security-Logging – und bei Integrationen mit Dritten klare Verträge darüber, welche Daten die Grenze überhaupt passieren dürfen.
Ich bin Entwickler und Architekt mit Security-Fokus – kein zertifizierter Penetrationstester und kein Auditor. Ich stelle keine Prüfsiegel aus und ersetze keinen formalen Pentest.
Meine Rolle ist eine andere, und sie kommt vorher: Anwendungen so entwerfen und bauen, dass ein späterer Pentest wenig zu finden hat – und wenn ein Pentest- oder Audit-Bericht bereits auf dem Tisch liegt, die Befunde im Code tatsächlich beheben.
Sie suchen die Leistung dazu? Konkrete Schwachstellen-Analyse und -Behebung finden Sie unter Anwendungssicherheit, Audit-Trails, Rechtekonzepte und Compliance unter Regulatorische Anforderungen.
Eine einmalige Prüfung veraltet mit dem nächsten Release. Deshalb verankere ich Sicherheit dort, wo sie dauerhaft wirkt:
Dann lassen Sie uns über Vertrauensgrenzen, Rechtekonzepte und Verschlüsselung sprechen,
bevor es jemand anderes tut – unverbindlich, 30 Minuten, kostenfrei.