Die kurze Antwort
Custom-Software-Sicherheit ist kein Add-on, das Sie am Ende kaufen — sie ist eine Reihe von Basisentscheidungen, die vom ersten Tag an in die Architektur eingebacken werden: Authentifizierung, Autorisierung, Eingabevalidierung, Secrets-Management und Audit-Logging. Wenn Sie das richtig machen, blockieren Sie 90 % der gängigen Angriffe. Wenn Sie es überspringen, schließt kein späteres Patching die Lücke vollständig.
Die OWASP-Basis, die jede Custom-App braucht
Der OWASP Top 10 listet die häufigsten Web-App-Sicherheitsrisiken auf. Für eine individuelle B2B-Anwendung sind die fünf wichtigsten: kaputte Zugriffskontrolle, kryptografische Fehler, Injection-Angriffe, unsicheres Design und Fehlkonfiguration. Das sind keine Theorien — das sind die Schwachstellen, die Jahr für Jahr in echten Breach-Reports auftauchen.
Authentifizierung: wer sind Sie?
Passwörter müssen gehasht werden, niemals im Klartext gespeichert. Nutzen Sie bcrypt oder Argon2 mit einem pro-benutzerspezifischen Salt. Erzwingen Sie eine Mindestpasswortrichtlinie (12+ Zeichen, kein Komplexitätstheater). Fügen Sie MFA für Admin-Konten hinzu — dieser eine Schritt blockiert die meisten Credential-Stuffing-Angriffe. Session-Tokens sollten ablaufen, HttpOnly und Secure gespeichert und beim Logout ungültig gemacht werden.
Autorisierung: was dürfen Sie tun?
Kaputte Zugriffskontrolle ist das OWASP-Risiko Nummer eins. Jeder API-Endpoint muss prüfen: ist dieser Nutzer eingeloggt? Hat dieser Nutzer die Berechtigung, genau diese Ressource zu erreichen? Verlassen Sie sich nicht darauf, UI-Buttons zu verstecken — die API muss Berechtigungen unabhängig erzwingen. Ein Nutzer sollte niemals auf die Daten eines anderen zugreifen können, indem er eine ID in der URL ändert.
Injection-Schutz: behandeln Sie jede Eingabe als feindselig
SQL-Injection, XSS und Command-Injection teilen eine Ursache: nicht vertrauenswürdige Daten, die als Code interpretiert werden. Nutzen Sie parametrisierte Queries für jeden Datenbankaufruf. Escapen Sie alle nutzergenerierten Inhalte, bevor Sie sie im Browser rendern. Konkatenieren Sie niemals Nutzereingaben in Shell-Kommandos. Das sind keine optionalen Best Practices — das ist das Minimum.
Secrets-Management: wo Ihre Schlüssel wohnen
API-Keys, Datenbank-Passwörter, Verschlüsselungsschlüssel und Dritt-Tokens sollten niemals im Quellcode hard-coded sein. Sie sollten in Umgebungsvariablen oder einem dedizierten Secrets-Manager liegen (AWS Secrets Manager, HashiCorp Vault). Sie sollten regelmäßig rotiert werden. Sie sollten niemals in der Git-History auftauchen — wenn ein Key in ein Repo committet wurde, behandeln Sie ihn als kompromittiert und rotieren Sie sofort.
Der Audit-Trail, den Sie nicht überspringen können
Protokollieren Sie jede wesentliche Aktion: wer sich eingeloggt hat, was er geändert hat, wann und von welcher IP. Diese Logs dienen nicht nur Compliance — sie sind, wie Sie einen Vorfall nachträglich erkennen. Ein Sicherheitsereignis, das nie protokolliert wird, ist ein Ereignis, das nie entdeckt wird. Speichern Sie Logs zentral, schützen Sie sie vor Manipulation und bewahren Sie sie mindestens 90 Tage auf.
Häufige Sicherheitsfehler in Custom-Projekten
- Wir fügen Sicherheit nach dem Launch hinzu — Sicherheit nachzurüsten kostet 3–5x mehr als sie von Anfang an einzubauen, und lässt immer Lücken.
- Sich auf Obskuranz verlassen — niemand weiß, dass es unsere App gibt, ist keine Sicherheitsstrategie. Automatisierte Scanner finden exponierte Admin-Panels in Stunden.
- Serverseitige Eingabevalidierung überspringen — Client-seitige Validierung ist für UX. Der Server muss jede Eingabe neu validieren, jedes Mal.
- Veraltete Abhängigkeiten nutzen — die meisten echten Breaches kommen von bekannten Schwachstellen in Drittbibliotheken, nicht von Custom-Code. Führen Sie monatlich Dependency-Scans durch.
- Kein Incident-Response-Plan — Sie werden einen Vorfall haben. Die Frage ist, ob Sie wissen, was zu tun ist, wenn es passiert.
Sicherheitsbudget: was es wirklich kostet
Bei einer individuellen B2B-Anwendung kostet die sicherheitsmäßige Berücksichtigung vom ersten Tag an roughly 15–25 % Aufschlag auf die Entwicklungskosten. Das deckt Authentifizierungssysteme, Autorisierungsmiddleware, Eingabevalidierung, Secrets-Management, Audit-Logging und grundlegende Penetrationstests. Es klingt teuer, bis Sie es mit der Alternative vergleichen: ein einziger Breach kann ein mittelständisches Unternehmen 200.000 bis 500.000 $ an Reaktion, Ausfallzeit und Anwaltskosten kosten — vor allen regulatorischen Bußgeldern.
Ihr Sicherheits-Checklist für den Launch
- Alle Passwörter mit bcrypt oder Argon2 gehasht.
- MFA für alle Admin-Konten aktiviert.
- HTTPS überall erzwungen, HSTS-Header gesetzt.
- Sicherheits-Header konfiguriert (CSP, X-Frame-Options, X-Content-Type-Options).
- Alle API-Endpoints erzwingen Autorisierungsprüfungen.
- Datenbank-Queries nutzen parametrisierte Statements.
- Secrets in Umgebungsvariablen, nicht im Code.
- Dependency-Scan ohne hochgradige Schwachstellen durchgeführt.
- Audit-Logging für alle sensiblen Aktionen aktiv.
- Backup und Wiederherstellung getestet.
FAQ zur Sicherheit
Kurze Antworten auf die Fragen, die uns am häufigsten zur Sicherheit individueller Software gestellt werden.
Ist individuelle Software sicherer oder unsicherer als Standardsoftware?
Es hängt ganz davon ab, wie sie gebaut wird. Standardsoftware profitiert von breiter Nutzung und öffentlicher Prüfung — Schwachstellen werden schnell gefunden und behoben. Individuelle Software wird weniger angegriffen, einfach weil sie obskur ist, aber wenn eine Schwachstelle existiert, schiebt kein Vendor einen Patch nach. Der Vorteil von individueller Software: Sie kontrollieren die Architektur und implementieren genau die Sicherheitskontrollen, die Ihr Unternehmen braucht. Das Risiko: wenn Ihr Entwickler die Sicherheitsgrundlagen übersprungen hat, kommt niemand, um Sie zu retten.
Brauchen wir Penetrationstests?
Bevor Sie sensible Kundendaten verarbeiten oder Zahlungen abwickeln, ja. Ein grundlegender Penetrationstest für eine individuelle Web-App kostet 3.000 bis 10.000 $ und findet typischerweise 5–10 echte Schwachstellen, die automatisierte Scanner übersehen. Für regulierte Branchen (Gesundheit, Finanzen) ist das nicht optional — das ist Compliance-Vorgabe.
Wie oft sollten wir die Sicherheit aktualisieren?
Drei Ebenen: (1) automatische Dependency-Scans monatlich; (2) eine Sicherheits-Review nach jedem größeren Feature-Release; (3) ein vollständiger Penetrationstest jährlich oder nach signifikanten Architekturänderungen. Sicherheit ist kein Häkchen — es ist eine laufende Praxis.
Mehr erfahren?
Kontaktieren Sie uns für ein kostenloses Angebot.