Was ist sichere Codierung?

Sichere Codierung, auch als sichere Programmierung bezeichnet, ist die Praxis, Quellcode so zu schreiben, dass er vor Cyberangriffen durch Bedrohungsakteure geschützt ist. Durch die Einbettung von Sicherheitsmaßnahmen in den Code lassen sich Sicherheitslücken reduzieren, wodurch Software entsteht, die robust und widerstandsfähig genug ist, um Cyberbedrohungen abzuwehren.

Sichere Programmierung ist ein wesentlicher Bestandteil des Secure Software Development Life Cycle (SSDLC). Im Gegensatz zum herkömmlichen SDLC, bei dem Sicherheitsaspekte erst in der Testphase berücksichtigt werden, bezieht der SSDLC die Cybersicherheit in jede Phase des Softwareentwicklungsprozesses mit ein. Codesicherheit ist nicht nur ein nachträglicher Einfall, ein optionales Zusatzmodul oder ein separater Aspekt, sondern ein wesentlicher Bestandteil der Entwicklung sicherer Software.

Sichere Codierung fällt ebenfalls unter den übergeordneten Begriff der Anwendungssicherheit. Während sich sicheres Programmieren auf die Integration von Cybersicherheit in den Code konzentriert, umfasst die Anwendungssicherheit ein breites Spektrum an Sicherheitsmaßnahmen – von Hardware-Schutzmaßnahmen bis hin zu softwarebasierten Abwehrmechanismen – und erstreckt sich über den gesamten Softwareentwicklungszyklus (SDLC).

Laut dem X-Force Threat Intelligence Index von IBM für das Jahr 2026 ist die Ausnutzung von Sicherheitslücken zur häufigsten Ursache für Angriffe geworden. Durch die Umstellung auf einen proaktiveren und präventiveren Ansatz, wie beispielsweise sicheres Programmieren, lassen sich Bedrohungen abfangen, bevor sie eskalieren.

Sichere Programmierung bietet folgende Vorteile:

• Kosteneffizienz: Es ist günstiger, Sicherheitslücken vor der Bereitstellung zu beheben als danach.

• Datensicherheit: Schutzmaßnahmen für sensible Daten werden bereits auf Quellcodeebene umgesetzt, wodurch die Einhaltung der Datenschutzbestimmungen gewährleistet wird.

• Frühzeitige Erkennung und Prävention: Schwachstellen werden bereits während der Entwicklung erkannt und beseitigt, sodass sie nicht in die Produktion übergehen können.

• Zeit- und Arbeitsersparnis: Sicherer Code kann dazu beitragen, den erheblichen Zeit- und Arbeitsaufwand zu vermeiden, der mit der Reaktion auf und der Behebung von Sicherheitsvorfällen bei laufenden Systemen verbunden ist.

Sicherheitslücken im Code resultieren in der Regel aus Mängeln im Software-Design und in der Architektur, aus Fehlkonfigurationen oder Programmierfehlern, um nur einige Beispiele zu nennen. Böswillige Akteure nutzen diese Sicherheitslücken häufig als Einstiegspunkte für Angriffe.

Im Folgenden finden Sie einige typische Sicherheitslücken, auf deren Behebung die sichere Programmierung abzielt. Diese basieren auf der Liste der Sicherheitsrisiken für Webanwendungen des Open Web Application Security Project (OWASP):

• Authentifizierungsfehler

• Fehlgeschlagene Zugriffskontrollen

• Kryptografische Fehler

• Injektionsangriffe

• Unsicheres Design

• Protokollierung und Benachrichtigung bei Fehlern

• Sicherheitsfehlkonfiguration

• Fehler bei der Software- oder Datenintegrität

Cyberkriminelle nutzen Schwachstellen in Authentifizierungsmechanismen aus, um Benutzerdaten zu stehlen und böswillige Aktivitäten durchzuführen. Zu den Authentifizierungsfehlern zählen schwache Passwortrichtlinien, das Fehlen sicherer Authentifizierungsmethoden, unsachgemäßes Sitzungsmanagement sowie unzureichender Schutz vor Passwort-Cracking-Verfahren wie Brute-Force-Angriffen, bei denen durch Ausprobieren die richtigen Passwörter ermittelt werden, oder Credential Stuffing, bei dem durch bereits kompromittierte Benutzernamen-Passwort-Kombinationen Zugriff auf Benutzerkonten erlangt wird.

Zugriffskontrollen legen fest, wer Zugriff auf Daten oder Ressourcen hat und welche Maßnahmen ausgeführt werden dürfen. Fehlerhafte oder nicht korrekt durchgesetzte Kontrollen können zu unberechtigtem Zugriff und Missbrauch von Berechtigungen führen. Zu Bedrohungen gehören das Ändern von API-Anfragen und URL-Parametern, um Zugriffskontrollprüfungen zu umgehen, oder unsichere direkte Objektverweise, die es ermöglichen, Daten oder Ressourcen direkt mit ihren eindeutigen Identifikatoren zu referenzieren, ohne die Berechtigungen zu überprüfen.

Fehler in kryptografischen Methoden können sensible Daten offenlegen und zu Data Breach führen. Zu den Fehlern in der Kryptographie zählen veraltete oder schwache Verschlüsselungsalgorithmen, mangelhafte Passwortverwaltungsprotokolle, die Verwendung fest codierter Passwörter sowie die Übertragung oder Speicherung von Daten ohne angemessene Verschlüsselung.

Injektionsangriffe gehören zu den häufigsten Typen von Sicherheitslücken. Böswillige Eingaben – Code, Befehle, Abfragen oder Skripte – werden in ein Programm oder eine Webseite eingeschleust, um unter anderem Malware zu starten, Daten zu verändern oder private Informationen zu stehlen. Cross-Site-Scripting, Cross-Site-Request-Forgery und Server-Side-Request-Forgery sind einige bekannte Injektionsangriffe.

Beim Cross-Site-Scripting (XSS) wird nicht vertrauenswürdiger Code oder nicht vertrauenswürdige Skripte auf vertrauenswürdigen Websites bereitgestellt, die dann von ahnungslosen Benutzern ausgeführt werden. Dies geschieht in der Regel, wenn eine Anwendung vom Benutzer bereitgestellte Daten nicht überprüft, filtert, bereinigt oder validiert.

Bei Cross-Site-Request-Forgery (CSRF oder XSRF) werden im Namen eines authentifizierten Benutzers unbefugte Anfragen an eine Website gesendet. Hierbei wird das Vertrauen ausgenutzt, das eine Website in den Webbrowser eines authentifizierten Benutzers setzt, indem Links oder Skripte eingesetzt werden, die den Browser dazu verleiten, böswillige Anfragen an eine Zielwebsite zu senden.

Bei einer serverseitigen Anfragefälschung (SSRF) werden an einen Server gesendete URLs manipuliert. Wenn der Server die manipulierte Anfrage annimmt, ohne zuvor die URL zu überprüfen, kann diese Anfrage dazu genutzt werden, eine Verbindung zu internen Diensten wie Datenbanken herzustellen oder Dateien, Serverkonfigurationen und andere Metadaten auszulesen.

Ein unsicheres Design bezieht sich auf Sicherheitslücken, die durch Mängel in der Geschäftslogik oder der Anwendungsarchitektur verursacht werden. Es tritt bereits in einer frühen Phase des SDLC auf, nämlich während der Planungsphase, wenn die Anforderungen definiert und die Mappings für die Systemarchitektur erstellt werden. Faktoren wie das Fehlen einer Risikobewertung, die begrenzte Nutzung sicherer Entwurfsmuster und Referenzarchitekturen sowie eine nur minimale Bedrohungsmodellierung zur systematischen Analyse potenzieller Sicherheitslücken in der geplanten Architektur können alle zu einem unsicheren Design beitragen.

Unzureichende oder ineffektive Warnmeldungen und Protokolle können zu unentdeckten Angriffen und Sicherheitslücken führen, wodurch Angreifer ernsthaften Schaden anrichten können. Einige Fälle von Protokollierung und Warnmeldungen beinhalten kritische Ereignisse, die nicht oder uneinheitlich protokolliert werden, unsichere Log-Speicher, die anfällig für Manipulationen oder unbefugten Zugriff sind, unzureichende Warnmeldungen für aktive Angriffe in Echtzeit oder nahezu in Echtzeit, Protokollnachrichten, die unklar oder ohne Kontext sind, sowie Protokolle, die sensible Daten enthalten, ohne dass diese maskiert oder bereinigt werden.

Diese Sicherheitslücke tritt auf, wenn die Sicherheitseinstellungen für den Anwendungsstack – einschließlich Cloud-Services, Datenbanken, Frameworks, Bibliotheken, Betriebssysteme und Webserver – nicht ordnungsgemäß konfiguriert sind. Zu den Fehlkonfigurationen zählen deaktivierte Sicherheitsupdates, zu weitreichende Zugriffsrechte, unveränderte Standard-Anmeldedaten und unnötige Funktionen, die aktiviert bleiben.

Diese Fehler stehen im Zusammenhang mit dem Fehlen von Sicherheitsvorkehrungen gegen die Annahme oder Verarbeitung ungültiger oder nicht vertrauenswürdiger Daten aus externen Quellen. Beispiele hierfür sind die automatische Installation von Software-Updates ohne Überprüfung ihrer Integrität, die Verwendung nicht vertrauenswürdiger Quellen für Abhängigkeiten wie Bibliotheken und Plugins von Drittanbietern sowie CI/CD-Pipelines, die Code oder andere Artefakte der Softwareentwicklung abrufen, ohne diese zu überprüfen.

Einige Technologien der generativen KI können bei der sicheren Programmierung helfen. So können beispielsweise agentische KI-Entwicklungsplattformen wie Claude Code und IBM Bob Sicherheitslücken aufdecken und in Echtzeit Korrekturen für unsicheren Code vorschlagen. Tools zur KI-gestützten Codegenerierung können zudem bei der Umgestaltung von Code helfen, um die Sicherheit zu verbessern.

Auch wenn KI-Codierungsassistenten die Softwareentwicklung automatisieren und beschleunigen können, benötigen sie dennoch Anweisungen, um sicheren Code zu generieren. Programmierer müssen klare Prompts bereitstellen, die nicht nur die Funktionalität, sondern auch die Sicherheitsanforderungen festlegen. Beispielsweise kann ein allgemeiner Prompt wie „Erstelle eine Anmeldefunktion“ um die Anweisung „Erstelle eine Anmeldefunktion, die Benutzereingaben auf das erwartete Format und die erwartete Länge überprüft“ erweitert werden, um Anweisungen für sicheres Codieren einzubeziehen. Der Leitfaden der Open Source Security Foundation enthält Beispielanweisungen, die KI-Assistenten dabei helfen sollen, die Codesicherheit zu gewährleisten.

Softwareentwicklungsteams können zudem den Kontext liefern, der generative KI dazu anleitet, sichereren Code zu erzeugen. Retrieval-Augmented Generation (RAG) verbindet KI-gestützte Entwickler-Tools mit internen Standards für sichere Codierung. Für Teams ohne definierte Richtlinien dienen die KI-Sicherheitsregeln von Secure Code Warrior als Ausgangspunkt für sichereren, KI-generierten Code.

Ähnlich wie KI-Assistenten profitieren auch KI-Codierungsassistenten von einer Anleitung. Project CodeGuard bietet ein Regelwerk und ein Kompetenz-Framework, das sichere Codierungspraktiken direkt in agentische Workflows integriert. Ein KI-Codierungsagent kann diese Regeln und Kompetenzen während der Planungsphase als Teil seiner Ziele und während der Ausführungsphase beim Schreiben von Code nutzen.

Von künstlicher Intelligenz selbst generierter Code kann Sicherheitslücken enthalten, sodass die endgültige Entscheidung über Genauigkeit und Sicherheit weiterhin bei menschlichen Programmierern liegt. Maßnahmen im Bereich der generativen KI müssen zudem mit den nachstehend aufgeführten Best Practices für sichere Codierung kombiniert werden, um mehrere Schutzebenen zu schaffen.

Best Practices im Bereich sicherer Codierung umfassen verschiedene defensive Programmierstrategien zur Stärkung der Softwaresicherheit. Unternehmen könnten Schwierigkeiten damit haben, eine sichere Codierung mit der Liefergeschwindigkeit in Einklang zu bringen. Viele dieser Praktiken integrieren Sicherheit in den Code, ohne die schnelle Bereitstellung zu beeinträchtigen, wie zum Beispiel die Einbeziehung von Sicherheit in die Designphase, die Festlegung von Richtlinien für sicheres Codieren, die Schulung von Entwicklern, damit diese in der Lage sind, Sicherheitslücken während der Codierung zu erkennen und zu beheben, und die Automatisierung von Codeanalyse und -tests, um Schwachstellen aufzudecken.

Auch wenn es unmöglich ist, alle Best Practices für sichere Codierung aufzuzählen, dient diese Liste als Ausgangspunkt, und die Kombination dieser Best Practices kann den Sicherheitsstatus eines Unternehmens verbessern:

• Befolgen Sie Standards für sicheres Programmieren

• Beziehen Sie Sicherheit in die Konzeption ein

• Validieren und bereinigen Sie Eingaben und verschlüsseln Sie Ausgaben

• Implementieren Sie starke kryptografische Protokolle

• Führen Sie Authentifizierung und Autorisierung durch

• Richten Sie robuste Protokollierungs- und sichere Fehlerbehandlungsmechanismen ein

• Führen Sie gründliche Sicherheitstests durch

• Beziehen Sie Sicherheitsaspekte in Code-Reviews ein

Diese Standards dienen als grundlegende Leitlinien für die effektive Integration sicherer Codierungstechniken in bestehende Workflows. Sie bieten eine gemeinsame Grundlage für sichere Codierung in allen Softwareprojekten.

Der OWASP-Entwicklerleitfaden ist ein Nachschlagewerk für Programmierer, das ihnen dabei hilft, sich zurechtzufinden und sicheren Quellcode zu erstellen. Der Leitfaden beschreibt technologieunabhängige Praktiken für sichere Codierung, wobei wichtige Aspekte der Codesicherheit in Checklisten hervorgehoben werden, die aus dem archivierten OWASP-Schnellreferenzleitfaden für sichere Programmierpraktiken übernommen wurden.

OWASP stellt zudem eine Reihe von Spickzetteln zur Umsetzung sicherer Prinzipien der Codierung und zur Bekämpfung einer Vielzahl von Sicherheitslücken bereit.

Die vom Software Engineering Institute der Carnegie Mellon University entwickelten SEI CERT-Codierungsstandards bieten Leitlinien für sichere Codierung in den Programmiersprachen Android, C, C++, Java und Perl. Die Standards enthalten Regeln, Empfehlungen sowie Beispiele für konformen und nicht konformen Code. Zu den Regeln und Empfehlungen gehören entsprechende Risikobewertungen, die nach Schweregrad, Eintrittswahrscheinlichkeit und Behebungskosten kategorisiert sind, um Softwareentwicklungsteams dabei zu helfen, ihre Maßnahmen zu priorisieren.

Neben seinem Cybersecurity Framework für Informationssicherheit und Risikomanagement im Bereich Cybersicherheit hat das National Institute of Standards and Technology (NIST) auch sein Secure Software Development Framework veröffentlicht. Das Framework umfasst übergreifende, ergebnisorientierte Praktiken für die sichere Softwareentwicklung und stellt somit eine ideale Ergänzung zu den eher technischen Standards von OWASP und SEI CERT dar.

Die Integration sicherer Entwürfe in die Systemplanung steht im Einklang mit dem „Shift-Left“-Ansatz, bei dem Sicherheitsaspekte bereits in einer früheren Phase des Softwareentwicklungsprozesses berücksichtigt werden. Dabei werden Möglichkeiten geprüft, wie Software bereits vor dem Schreiben der ersten Codezeile sicher gestaltet werden kann.

Umfassende Risikobewertungen und Bedrohungsmodellierung können dazu beitragen, potenzielle Sicherheitslücken in der Softwarearchitektur aufzudecken. In der Phase der sicheren Entwicklung müssen zudem Sicherheitsteams einbezogen werden, um eine enge Zusammenarbeit zu gewährleisten und Beratung hinsichtlich der Sicherheitsanforderungen sowie deren Umsetzung auf Quellcodeebene zu bieten.

Weitere Informationen zur Integration von Sicherheit in den Designprozess finden Teams in den OWASP-Spickzetteln zu sicherem Produktdesign und Bedrohungsmodellierung sowie im Secure by Design-Framework.

Ein zentraler Grundsatz der sicheren Codierung lautet, niemals einer Eingabe zu vertrauen, wie Injektionsangriffe zeigen. Serverseitige Validierung und Bereinigung tragen dazu bei, sicherzustellen, dass Eingaben keine Sicherheitsrisiken darstellen, bevor sie verarbeitet werden.

Softwareentwicklungsteams können die gesamte Validierungs- und Bereinigungslogik in einer sicheren zentralen Datei oder an einem zentralen Speicherort ablegen, um die Konsistenz zu gewährleisten und einen schnellen und einfachen Zugriff sowie Aktualisierungen zu ermöglichen. Sie können auch die in Programmiersprachen und Frameworks integrierten Validierungs- und Bereinigungsmodule nutzen, doch diese müssen regelmäßig aktualisiert werden, um neu entdeckte Sicherheitslücken zu schließen.

Die Eingabevalidierung überprüft, ob die Typen, das Format, die Länge, der Bereich, die Größe und andere Einschränkungen korrekt sind. Dies kann den Abgleich der Eingaben mit genehmigten Mustern oder den Vergleich mit einem zulässigen Zeichensatz oder Wertebereich umfassen.

Die Bereinigung von Eingaben umfasst deren Reinigung und Umwandlung in eine sichere Form. Sie muss auf eine bestimmte Programmiersprache oder ein bestimmtes Framework zugeschnitten sein.

In HTML kann beispielsweise das Entkommen von Sonderzeichen wie &, <, >, „ und ‘ dazu beitragen, XSS zu verhindern. Bibliotheken wie DOMPurify können bei der HTML-Bereinigung helfen.

Bei Datenbanken kann die Kombination von parametrisierten Abfragen mit vorbereiteten Anweisungen dazu beitragen, SQL-Injection-Angriffe zu verhindern, da Eingaben als Daten und nicht als SQL-Code behandelt werden, der versehentlich ausgeführt werden könnte. Bei parametrisierten Abfragen wird zunächst der gesamte SQL-Code mit Platzhaltern für Eingaben oder Parameter definiert; anschließend wird jeder Parameter der Abfrage übergeben. Vorbereitete Anweisungen sind vorkompilierte SQL-Anweisungen, was bedeutet, dass eingeschleuste SQL-Befehle weder die Absicht einer Abfrage noch deren Ausführung verändern können.

Durch die Ausgabekodierung können Daten sicher als Text angezeigt werden, sodass sie nicht als Code interpretiert werden. Viele Frameworks verfügen standardmäßig über einen Ausgabekodierungsschutz oder automatische Kodierungs- und Escaping-Funktionen. Der OWASP Java Encoder unterstützt die kontextbezogene Ausgabekodierung für verschiedene Kontexte, beispielsweise das Einfügen von Variablen in eine URL, in Inline-CSS oder Inline-JavaScript sowie das Einfügen von Variablen in einen HTML-Attributwert, eine CSS-Eigenschaft oder zwischen zwei HTML-Tags.

Bei korrekter Anwendung gewährleistet die Kryptografie die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen.

Programmierer müssen bei der Verschlüsselung von Daten während der Übertragung und im Ruhezustand aktuelle und sichere Algorithmen verwenden. AES gilt als Goldstandard für die symmetrische Verschlüsselung; dank authentifizierter Modi und eines 256-Bit-Schlüssels bietet es ein hohes Maß an Sicherheit. Bei der asymmetrischen Verschlüsselung bieten ECC mit einer sicheren Kurve oder RSA mit aktivierter Zufallsauffüllung und einem Schlüssel von mindestens 2048 Bit robuste Sicherheit.

Um Passwörter zu schützen, müssen Hash-Algorithmen angewendet und dem Passwort im Rahmen des Hash-Vorgangs ein Salt – eine eindeutige, zufällig generierte Zeichenfolge – hinzugefügt werden. Ein Hash-Algorithmus ist eine mathematische Einwegfunktion, die Daten in einen eindeutigen, kürzeren Wert mit fester Länge umwandelt, der nicht entschlüsselt oder rückgängig gemacht werden kann. Zu den modernen Hash-Algorithmen gehören Argon2id und scrypt.

Anstatt eigene Lösungen zu entwickeln, sollten Entwickler auf zuverlässige, unterstützte und gepflegte Implementierungen von Kryptografie-Bibliotheken wie Bouncy Castle, Libsodium, OpenSSL und Tink zurückgreifen.

Schlüssel dürfen nicht fest in der Codierung des Quellcodes hinterlegt, in Versionskontrollsystemen eingecheckt, in Umgebungsvariablen gespeichert oder in Protokollen offengelegt werden. Lösungen und Technologien zur Schlüsselverwaltung können dabei helfen, den gesamten Lebenszyklus der Schlüsselverwaltung zu automatisieren – von der Generierung, Verteilung und Speicherung bis hin zur Nutzung, Rotation, Sperrung und Vernichtung.

Was den Schutz auf Transportschicht angeht, müssen Softwareentwicklungsteams Protokolle wie das Hypertext Transfer Protocol Secure (HTTPS) oder HTTP Strict Transport Security (HSTS) sowie die neueste Version von TLS verwenden. Das Zwischenspeichern sensibler Daten muss deaktiviert und eine unnötige Speicherung sensibler Daten vermieden werden.

Authentifizierung und Autorisierung sind entscheidende Praktiken für sichere Codierung, um die Identität einer Entität zu validieren und sicherzustellen, dass diese Entität über die entsprechenden Zugriffsrechte verfügt.

Multifaktor-Authentifizierung (MFA) ist eine der besten Schutzmaßnahmen gegen passwortbezogene Angriffe. Weitere Mechanismen umfassen Login-Throttling, um zu verhindern, dass Hacker zu oft Passwörter erraten, sowie Kontosperrungen, um Anmeldeversuche nach mehreren fehlgeschlagenen Anmeldungen für einen bestimmten Zeitraum zu stoppen.

Für die passwortlose Authentifizierung können Entwickler Protokolle wie OpenID Connect (OIDC) und Security Assertion Markup Language (SAML) in Betracht ziehen. Die offenen Standards FIDO und FIDO2 ermöglichen die passwortlose Authentifizierung mittels Passkeys und können zur Authentifizierung von Anwendungen, Online-Diensten und Websites verwendet werden.

Sobald eine authentifizierte Sitzung hergestellt wurde, muss diese durch sichere Sitzungs-IDs oder Token aufrechterhalten werden. Sitzungs-IDs müssen mithilfe eines starken, kryptografisch sicheren Pseudozufallszahlengenerators erzeugt werden. Wie bei jeder anderen Benutzereingabe müssen Sitzungs-IDs oder Token vor der Verarbeitung validiert und ungültige Werte herausgefiltert werden.

Durch die Festlegung von Zeitlimits für jede Sitzung wird der Zeitraum begrenzt, in dem böswillige Akteure aktive Sitzungen kapern und Angriffe starten können. Softwareentwicklungsteams können die integrierten Funktionen zur Sitzungsverwaltung nutzen, die von Web-Frameworks bereitgestellt werden.

Programmierer können Autorisierungsprotokolle wie OAuth einsetzen, das mit dem OIDC-Authentifizierungsprotokoll zusammenarbeitet. Im Bereich der Zugriffskontrolle ist die rollenbasierte Zugriffskontrolle (RBAC) ein gängiges Modell, bei dem Benutzern der Zugriff auf der Grundlage ihrer vordefinierten Rolle gewährt wird. Weitere Optionen, die robuster sein können und eine feinere Berechtigungssteuerung ermöglichen, sind die attributbasierte Zugriffskontrolle (ABAC) und die beziehungsbasierte Zugriffskontrolle (ReBAC). ABAC analysiert die Attribute von Aktionen, Objekten und Benutzern – wie beispielsweise den Namen eines Benutzers, den Typ einer Ressource und die Tageszeit –, um zu bestimmen, ob Zugriff gewährt wird. ReBAC gewährt Zugriff auf der Grundlage der Beziehungen zwischen Ressourcen.

Selbst wenn Protokolle und Zugriffskontrollmodelle vorhanden sind, müssen die Berechtigungen bei jeder Anfrage überprüft und für jedes Objekt, auf das eine Entität zugreifen möchte, Zugriffskontrollen durchgeführt werden. Der standardmäßige Zugriffsverweigerung und die Anwendung des Prinzips der geringsten Berechtigungen sind ebenfalls wesentliche Grundsätze der sicheren Codierung, wenn es um die Autorisierung geht.

Protokolle und Fehlermeldungen können eine reichhaltige Informationsquelle darstellen, die böswilligen Akteuren bei der Planung von Angriffen hilft. Das bedeutet, dass sowohl Protokolle als auch Fehlermeldungen mit Bedacht behandelt werden müssen.

Anwendungsfehler, Systemereignisse im Zusammenhang mit Konfigurationsänderungen sowie Administrator- oder privilegierte Aktionen und Fehlerereignisse in den Bereichen Authentifizierung, Autorisierung, Eingabevalidierung und Sitzungsverwaltung müssen alle protokolliert werden, da diese auf Angriffsversuche hindeuten können. Es müssen ausreichende Informationen enthalten sein, wie beispielsweise Benutzerdaten (Identität, Rollen und Berechtigungen) sowie der Kontext des Fehlers oder Ereignisses (Ziel, Aktion und Ergebnis), um die Analyse und Debugging zu erleichtern.

Protokolle müssen auf schreibgeschützte Datenträger geschrieben und an einem sicheren Ort mit beschränktem Zugriff und integrierter Manipulationserkennung aufbewahrt werden. Müssen Protokolle an andere Systeme übermittelt werden, ist ein sicheres Übertragungsprotokoll zu verwenden.

Sensible Daten dürfen nicht protokolliert werden und müssen aus den Protokollen entfernt oder gelöscht werden. Alle anderen als kritisch eingestuften Informationen, wie beispielsweise Datenbankverbindungszeichenfolgen, Dateipfade, interne Netzwerknamen und -adressen sowie Sitzungs-IDs oder Tokens, müssen verschlüsselt, gehasht oder maskiert werden.

Protokollierungsbibliotheken müssen regelmäßig aktualisiert werden, um sicherzustellen, dass Sicherheitslücken behoben werden. Dies zeigt die Log4Shell-Sicherheitslücke, die die weit verbreitete Open-Source-Protokollierungsbibliothek Log4j betrifft und es Hackern ermöglicht, auf betroffenen Systemen nahezu beliebigen Code auszuführen.

Die Fehlerbehandlung geht Hand in Hand mit der Protokollierung, da Informationen zu Fehlern in der Regel in Protokollen erscheinen. Und unbehandelte Fehler können Bedrohungsakteuren als Einfallstor dienen.

Entwickler können die Erstellung einer globalen Fehlersteuerung in Betracht ziehen, die bei unerwarteten Fehlern eine generische Antwort oder einen Fehlercode zurückgibt und anschließend serverseitig weitere Details zum Fehler protokolliert. Dadurch wird vermieden, dass Informationen an Hacker gelangen, während gleichzeitig Fehler sicher behandelt und die notwendigen Erkenntnisse für weitere Untersuchungen durch Programmierer bereitgestellt werden.

Alle in den Quellcode integrierten Sicherheitsmaßnahmen müssen überprüft werden. QA- und Entwicklungsteams können sich auf den Web Security Testing Guide und den Application Security Verification Standard der OWASP als Grundlage für die Überprüfung der Codesicherheit stützen. Automatisierte Tools können den Prozess ebenfalls unterstützen.

Bei statischen Anwendungssicherheitstests (SAST) werden vordefinierte Regeln angewendet, um Muster im Code zu identifizieren, die auf mögliche Sicherheitslücken hindeuten. SAST wird manchmal auch als „White-Box“-Test bezeichnet, während SAST-Tools zudem als statische Code-Analysatoren bekannt sind, da sie den Code scannen, ohne dass die Anwendung ausgeführt werden muss.

SAST-Tools sind hervorragend dafür geeignet, häufige Code-Schwachstellen zu markieren und die genaue Zeilennummer und Datei der gefundenen Sicherheitslücken zu bestimmen. Sie integrieren sich außerdem nahtlos in die meisten IDEs und CI/CD-Umgebungen. Allerdings sind sie anfällig auf Fehlalarme.

Dynamische Anwendungssicherheitstests (DAST) verfolgen einen externen Ansatz und bewerten Anwendungen in ihren Laufzeitumgebungen mithilfe simulierter Angriffe, um die Handlungen realer Bedrohungsakteure nachzuahmen. Daher wird DAST oft als Blackbox-Testing bezeichnet, da Tester nicht über die internen Abläufe oder den Quellcode eines Systems informiert werden oder darauf zugreifen müssen. DAST liefert in der Regel weniger Fehlalarme als SAST.

Durch die Kombination von SAST und DAST lässt sich ein umfassenderes Bild potenzieller Sicherheitslücken gewinnen. Für noch umfassendere Sicherheitstests können SAST und DAST mit anderen Methoden kombiniert werden, wie beispielsweise dem interaktiven Anwendungssicherheitstest (IAST), der sowohl den Code-Kontext als auch das Laufzeitverhalten bewertet, um Sicherheitslücken in Echtzeit zu melden, sowie der Software-Kompositionsanalyse (SCA), die Software analysiert, um sicherzustellen, dass ihre Komponenten sicher und auf dem neuesten Stand sind.

Bei den meisten Code-Reviews steht die Qualität im Vordergrund; dabei wird der Code auf die Einhaltung von Stilrichtlinien, logische Probleme, einen optimalen Ablauf sowie die Abdeckung von Test- und Randfällen überprüft. Doch auch die Sicherheit muss Teil des Code-Review-Prozesses sein.

Sichere Code-Reviews fungieren als nächste Verteidigungslinie nach statischen Code-Analysatoren. Menschliche Code-Reviewer bieten Fachwissen, Urteilsvermögen und Einblicke in Sicherheitslücken im Code, die automatisierte Tools oft übersehen.

Für einen strukturierteren Ansatz können Code-Prüfer das OWASP-Spickzettel für die sichere Code-Prüfung zu Rate ziehen.