6 bewährte Verfahren zur Angular-Sicherheit für Entwicklerteams im Jahr 2026

Wichtigste Erkenntnisse

• Angular führt standardmäßig eine Escape-Verarbeitung für interpolierte Inhalte durch, bereinigt nicht vertrauenswürdige HTML- und URL-Werte in Vorlagenbindungen und übernimmt die clientseitige CSRF-Absicherung. Ein vollständiger Schutz hängt jedoch davon ab, dass Ihr Server das Token ausstellt und validiert.
• XSS, CSRF, Sicherheitslücken bei der Autorisierung und nicht gepatchte Abhängigkeiten sind die Risiken, von denen Angular-Anwendungen am häufigsten betroffen sind, und die meisten davon entstehen außerhalb der standardmäßigen Schutzmaßnahmen des Frameworks.
• Eine Content Security Policy, „Trusted Types“ und „Subresource Integrity“ für Skripte von Drittanbietern decken Angriffsflächen ab, in die Angular keinen Einblick hat.
• Angular-Versionen 19 und älter haben das Ende ihrer Lebensdauer erreicht und erhalten keine offiziellen Sicherheitspatches mehr; Teams, die noch nicht migrieren können, benötigen einen Plan, um weiterhin geschützt zu bleiben.

 

Angular-Anwendungen werden selten aufgrund einer Schwachstelle im Framework selbst kompromittiert. Sie werden kompromittiert, weil ein Entwickler auf bypassSecurityTrustHtml verwendet hat, um die korrekte Darstellung eines Widgets eines Drittanbieters zu gewährleisten, und dabei den XSS-Schutz von Angular für diesen Wert deaktiviert hat. Oder weil das Backend ein XSRF-Token nie validiert hat. Oder weil eine drei Ebenen tiefer liegende Abhängigkeit zwei Jahre lang ohne Patch blieb. Das ist das Muster hinter den meisten Sicherheitsproblemen bei Angular: Das Framework ist solide; die Workarounds und die umgebende Konfiguration hingegen nicht.

Dieser Leitfaden behandelt die Sicherheitsmaßnahmen in Angular, die die Lücke zwischen dem, was das Framework automatisch schützt, und dem, was Ihr Team manuell umsetzen muss, schließen.

Wie Angular die Sicherheit handhabt

 

Bevor Sie eine Angular-App absichern können, ist es hilfreich zu wissen, was Angular bereits für Sie leistet. Wie sich herausstellt, ist das eine ganze Menge.

Standardmäßig behandelt Angular jeden Wert als nicht vertrauenswürdig. Wenn ein Wert durch Interpolation oder eine Template-Bindung in das DOM eingefügt wird, führt Angular eine Escape-Verarbeitung oder Bereinigung durch. Interpolierte Inhalte werden immer mit Escape-Zeichen versehen, daher {{ }} das Markup als sichtbaren Text rendert, anstatt es zu parsen. Eigenschaftsbindungen durchlaufen eine kontextbezogene Bereinigung, wobei die Regeln vom jeweiligen Kontext abhängen. Angular definiert vier Sicherheitskontexte – HTML, Style, URL und Ressourcen-URL – und bereinigt nicht vertrauenswürdige HTML- und URL-Werte. Ressourcen-URLs können nicht bereinigt werden, da sie per Definition Code laden und ausführen; daher lehnt Angular deren Bindung ab, sofern Sie sie nicht explizit als vertrauenswürdig kennzeichnen. Dieses Verhalten blockiert den Großteil der einfachen XSS-Versuche.

Angular kompiliert Vorlagen in CLI-Anwendungen standardmäßig im Voraus, wodurch Fehler im Zusammenhang mit der Vorlagen-Einbindung vermieden werden, und seine HttpClient verfügt über eine clientseitige XSRF-Token-Verarbeitung und entfernt automatisch XSSI-Antwortpräfixe.

Diese Schutzmaßnahmen greifen nur, solange Sie sich innerhalb dieser Grenzen bewegen. Schreiben Sie direkt in das DOM über ElementRefdirekt an das DOM, übergeben Sie einen umgangenen Wert an eine Bindung oder lassen Sie Ihren Server die XSRF-Validierung überspringen – und schon gelten die Garantien nicht mehr. In den folgenden Abschnitten geht es um die Lücken, die Angular nicht automatisch schließt.

Realitätscheck: „Angular ist standardmäßig sicher“ ist nur zur Hälfte richtig. Angular führt eine Escape- und Sanitizing-Prüfung der Template-Ausgabe durch und stellt clientseitige Helper für CSRF und XSSI bereit, unternimmt jedoch nichts gegen durchgesickerte Tokens, anfällige npm-Pakete, schwache Authentifizierung oder eine EOL-Version, die öffentlichen CVEs ausgesetzt ist. Das Framework schützt bestimmte Teile des clientseitigen Renderings und der HTTP-Schichten, nicht jedoch Ihre gesamte Anwendung.

Häufige Sicherheitslücken in Angular

Hier ist die unangenehme Wahrheit: Die meisten Sicherheitslücken in Angular-Anwendungen sind keine Fehler in Angular selbst. Es handelt sich um Stellen, an denen ein Entwickler die Schutzmechanismen des Frameworks umgangen hat – meist, um eine Funktion schneller bereitstellen zu können, ohne eine gleichwertige Sicherheitsmaßnahme einzubauen.

Schwachstelle	Wie es in Angular entsteht	Was Angular abdeckt und was nicht
XSS	Nicht vertrauenswürdige Daten, die mit bypassSecurityTrust*als sicher markiert oder über ElementRef oder element.innerHTML	Die kontextbezogene Bereinigung gilt für Template-Bindungen, nicht für direkte DOM-Schreibvorgänge.
CSRF	Der Server setzt oder überprüft das XSRF-Token niemals.	HttpClient sendet das Token; der Server muss es ausstellen und überprüfen
Anfällige Abhängigkeiten	Veraltete npm-Pakete oder eine Angular-Version, deren Lebensdauer abgelaufen ist	Upstream-Patches werden nach Ablauf der Lebensdauer eingestellt
Fehlerhafte Zugriffskontrolle	Serverseitige Autorisierung fehlt oder ist inkonsistent; Routen-Guards fehlen oder sind falsch konfiguriert	Clientseitige Schutzmaßnahmen können keine serverseitige Zugriffskontrolle durchsetzen
Einfügen von Skripten durch Dritte	Externe Skripte, die ohne SRI- oder CSP-Kontrollen geladen werden	Angular führt keine Sandbox-Isolierung für Code von Drittanbietern durch

Cross-Site Scripting (XSS)

XSS ist die Sicherheitslücke, auf deren Verhinderung das Sicherheitsmodell von Angular am deutlichsten ausgerichtet ist. Das gesamte Sanitisierungssystem existiert, weil das Einfügen nicht vertrauenswürdiger Inhalte in das DOM so zuverlässig ausgenutzt wird – und genau das macht die Sanitisierung von Angular zu dem Schutzmechanismus, den Entwickler am häufigsten versehentlich deaktivieren, wenn sie nach einer Umgehungsmöglichkeit suchen.

Der „Synopsys Open Source Security and Risk Analysis Report 2024“, in dem mehr als 1.000 kommerzielle Codebasen analysiert wurden, ergab, dass acht der zehn häufigsten Open-Source-Schwachstellen der Kategorie CWE-707 zuzuordnen waren – einer weit gefassten Klasse namens „unsachgemäße Neutralisierung“, die Schwachstellen umfasst, die durch den unsicheren Umgang mit nicht vertrauenswürdigen Eingaben entstehen, darunter auch Cross-Site-Scripting. Unsachgemäßer Umgang mit Eingaben ist kein Einzelfall, sondern eine der zuverlässigsten Ursachen für schwerwiegende Schwachstellen im gesamten Open-Source-Ökosystem.

In Angular-Anwendungen lässt sich XSS in der Regel auf eine von drei Ursachen zurückführen: ein DomSanitizer.bypassSecurityTrustHtml() -Aufruf für Daten, auf die ein Angreifer Einfluss nehmen kann, Inhalte, die an einer früheren Stelle fälschlicherweise als vertrauenswürdig markiert wurden, oder Code, der über ElementRef, native Browser-APIs oder eine Drittanbieter-Bibliothek, die außerhalb der Kontrolle von Angular operiert, direkt in das DOM schreibt. Ein reines [innerHTML] -Bindung wird dagegen bereinigt.

Die Lösung ist nicht kompliziert. Leiten Sie keine nicht vertrauenswürdigen Daten über einen Bypass weiter, und wenn Sie extern bereitgestelltes HTML wirklich rendern müssen, bereinigen Sie es mit einem gut gewarteten Sanitizer, bevor es die Vorlage erreicht. Behandeln Sie jedes bypassSecurityTrust* -Aufruf in Ihrem Code als einen Fund, der eine genauere Überprüfung wert ist.

Achtung: Jedes bypassSecurityTrust* -Methode tut genau das, was der Name sagt: Sie deaktiviert die Bereinigung durch Angular für diesen Wert. DomSanitizer.sanitize() bereinigt keinen Wert, der bereits als vertrauenswürdig markiert wurde; daher bringt es nichts, einen „bypass“ in einen „sanitize“-Aufruf einzubinden. Schon ein einziger solcher Aufruf in einem Feld, auf das ein Angreifer Zugriff hat, reicht für eine „Stored XSS“-Schwachstelle aus. Suchen Sie vor jedem Release gezielt danach.

Cross-Site Request Forgery (CSRF)

CSRF in Angular ist in der Regel auf eine Konfigurationslücke zurückzuführen und kein Programmierfehler. Standardmäßig liest der HttpClient das XSRF-TOKEN und sendet es als X-XSRF-TOKEN -Header bei mutierenden Anfragen an relative URLs und URLs derselben Herkunft zurück. Bei GET oder HEAD -Anfragen, die ihn nicht benötigen, oder bei ursprungsübergreifenden Anfragen. Die clientseitige Verarbeitung erfolgt.

Das Problem liegt in der anderen Hälfte. Angular kann dieses Cookie nicht setzen und das zurückgegebene Token nicht für Sie validieren. Wenn Ihr Backend das Cookie niemals ausstellt oder Anfragen ohne diesen Header akzeptiert, ist der Schutz reine Augenwischerei. Die Dokumentation von Angular selbst drückt es ganz unverblümt aus: Wird der Server nicht entsprechend konfiguriert, ist der Standardschutz wirkungslos. Dies ist eines der häufigsten Probleme bei Single-Page-Anwendungen – das Frontend wirkt geschützt, während der Server keine Überprüfung durchführt.

Sicherheitslücken aufweisende und veraltete Abhängigkeiten

Dies ist der größte versteckte Schwachpunkt, den Teams am längsten übersehen. Der Code Ihrer App mag zwar übersichtlich sein, aber Ihre `node_modules`-Verzeichnis gehört nicht Ihnen, und ein großer Teil dessen, was darin landet, kommt als indirekte, transitive Abhängigkeiten , die niemand in Ihrem Team ausgewählt hat.

Der „Black Duck Open Source Security and Risk Analysis Report 2026“, in dem 947 kommerzielle Codebasen aus 17 Branchen untersucht wurden, untermauert mit Zahlen, was die meisten Teams zwar bereits ahnen, aber selten in die Tat umsetzen. Von diesen Codebasen enthielten 93 % Komponenten, bei denen seit mindestens zwei Jahren keine Entwicklungsaktivitäten mehr stattfanden, 92 % wiesen Komponenten auf, die 10 oder mehr Versionen hinter den aktuellen Releases zurücklagen, und nur 7 % der Komponenten befanden sich auf der neuesten verfügbaren Version. Die durchschnittliche Anzahl der Schwachstellen pro Codebasis hat sich im Vergleich zum Vorjahr mehr als verdoppelt und lag bei 581. Die Ergebnisse zu jQuery sind besonders aufschlussreich: Vier der zehn häufigsten CVEs in den untersuchten Codebasen waren jQuery-Schwachstellen, die bereits vor Jahren behoben wurden, und zwischen 25 % und 28 % der Codebasen wiesen immer noch mindestens eine davon auf.

Es laufen zwei Uhren. Die erste ist Ihr npm-Abhängigkeitsbaum, in dem sich CVEs ansammeln, unabhängig davon, ob Sie ihn nutzen oder nicht. Die zweite ist Angular selbst.

Angular hat mit Version 22 seinen Release-Rhythmus geändert. Hauptversionen erscheinen nun jährlich und werden in der Regel 24 Monate lang unterstützt: 12 Monate aktiver Support, gefolgt von 12 Monaten LTS, in denen nur kritische Fehlerbehebungen und Sicherheitspatches bereitgestellt werden. Alle Releases bis einschließlich Version 21 folgten dem älteren sechsmonatigen Rhythmus und einem 18-monatigen Zeitfenster – 6 Monate aktiver Support, dann 12 Monate LTS. In beiden Fällen endet der Support.

Angular-Version	Stand (August 2026)	Die aktive Unterstützung endet	Der Sicherheits-Support (LTS) endet
22	Aktiv	Juni 2027	Juni 2028
21	LTS	Beendet am 3. Juni 2026	Juni 2027
20	LTS	Beendet am 19. November 2025	November 28, 2026
19 und jünger	Ende des Lebens	–	Keine offiziellen Patches

Die Termine richten sich nach dem von Angular veröffentlichten Support-Zeitplan, den das Team als ungefähre Richtlinie bereitstellt und der Änderungen unterliegen kann.

Sobald Sie eine EOL-Version verwenden, erhalten Sie keine routinemäßigen Sicherheitsupdates mehr vom Upstream-Entwickler. Daher bleiben alle neuen CVEs, die das Framework oder dessen Quellcode betreffen, ungepatcht, es sei denn, Sie führen ein Upgrade durch oder nehmen den Support eines Anbieters in Anspruch. Wir werden später noch darauf zurückkommen, wie Sie in diesem Fall vorgehen sollten.

Bewährte Verfahren zur Angular-Sicherheit für Entwicklerteams

1. Vertraue dem Desinfektionsmittel, umgeh es nicht mehr

Die sinnvollste Vorgehensweise ist es, die Sanitisierung von Angular aktiviert zu lassen. Verwenden Sie standardmäßig Interpolation und Eigenschaftsbindung, da diese automatisch eine Escape-Verarbeitung und Sanitisierung durchführen. Ein normales [innerHTML] -Bindung wird bereinigt und ist daher an sich nicht unsicher – verwenden Sie sie jedoch nur, wenn Sie tatsächlich Markup rendern müssen, und kombinieren Sie sie niemals mit von Angreifern kontrolliertem Inhalt und einer Umgehungsmöglichkeit.

Wenn Sie wirklich extern bereitgestelltes HTML ausgeben müssen, bereinigen Sie es mit einem gut gewarteten HTML-Sanitizer, der auf Ihr Bedrohungsmodell zugeschnitten ist, und denken Sie daran, dass DomSanitizer.sanitize() keinen Wert bereinigt, der bereits von einem bypassSecurityTrust* -Aufruf umschlossen ist. Machen Sie Bypass-Aufrufe überprüfbar: Eine Lint-Regel oder ein CI-Grep, das jeden einzelnen davon markiert, zwingt einen Menschen dazu, dies zu begründen. Wenn bei einem Sicherheitsaudit ein Bypass bei für Angreifer zugänglichen Daten festgestellt wird, behandeln Sie dies als Release-Blocker und nicht als Backlog-Eintrag.

Profi-Tipp: Durchsuche deinen Code nach bypassSecurityTrust . Wenn Sie eine solche Stelle finden und nicht in einem Satz erklären können, warum dieser bestimmte Wert sicher ist, ist er es wahrscheinlich nicht.

 2. Fügen Sie eine Content Security Policy (CSP) hinzu

Eine Content Security Policy (CSP) ist Ihre zweite Verteidigungslinie gegen XSS-Angriffe, die die Bereinigung umgehen. Die CSP schränkt ein, welche Quellen und Ausführungsmuster der Browser zulässt, sodass eingeschleuste Skripte, die die Richtlinie nicht erfüllen, nicht ausgeführt werden. Inwieweit sie tatsächlich blockiert, hängt von der von Ihnen festgelegten Richtlinie ab: weit gefasste Ursprünge, „unsafe-inline“oder großzügige Skriptlademuster lassen viel durch.

Angular dokumentiert eine Mindestanforderung für eine neue Anwendung:

Content-Security-Policy: default-src ‚self‘; style-src ‚self‘ ‚nonce-randomNonceGoesHere‘;     script-src ‘self’ ‘nonce-randomNonceGoesHere’;

 The nonce matters. Angular inserts <style> elements at runtime, and a strict policy without a nonce will block them and break your styling. Generate a fresh, unpredictable nonce for every response and hand it to Angular in one of three supported ways: set autoCsp to true in your workspace configuration, set the ngCspNonce attribute on the root application element, or provide it through the CSP_NONCE injection token. Serve the policy as a response header from your web server or CDN, not as a meta tag. If your HTML is cached at a CDN, generate the nonce at the edge – a nonce baked into a cached response is the same value for every visitor, which defeats the point.

Kombinieren Sie CSP mit „Trusted Types“. Angular empfiehlt dringend, beide zu verwenden, da sie auf DOM-Ebene arbeiten und dort nicht über Browser-APIs auf niedrigerer Ebene umgangen werden können. Anwendungen, die eine der folgenden Funktionen aufrufen: bypassSecurityTrust* aufrufen, benötigen das angular#unsafe-bypass -Richtlinie, und Anwendungen mit verzögert geladenen Chunks benötigen angular#bundler.

Profi-Tipp: Führen Sie CSP zunächst im reinen Berichtsmodus mit Content-Security-Policy-Report-Only. So erhalten Sie Berichte über Verstöße, ohne die App zu beeinträchtigen, und können so jedes Inline-Skript, jeden eingefügten Stil und jede Herkunft von Drittanbietern identifizieren, bevor Sie die Richtlinie durchsetzen. Teams, die diesen Schritt überspringen, verursachen fast immer Probleme in der Produktionsumgebung.

 3. XSRF/CSRF-Schutz durchgängig konfigurieren

Gehen Sie nicht davon aus, dass die clientseitige XSRF-Abwicklung von Angular schon alles ist. Angular sendet das Token; Ihr Server muss es ausstellen und überprüfen.

Same-Origin-API: Stellen Sie sicher, dass das Backend das XSRF-TOKEN pro Sitzung in einem für JavaScript lesbaren Cookie setzt und alle berechtigten Anfragen ablehnt, bei denen der Header fehlt oder nicht übereinstimmt. Falls Ihr Backend andere Bezeichnungen verwendet, konfigurieren Sie diese mit withXsrfConfiguration() , anstatt den Interceptor zu deaktivieren.

Cross-Origin-API: Angular fügt den Header nicht zu Cross-Origin-Anfragen hinzu, sodass das standardmäßige Cookie-basierte Schema nicht zur Anwendung kommt. Entwerfen Sie den Schutz bewusst auf beiden Seiten: Cookie-Attribute, Umgang mit Anmeldedaten, eine explizite Liste vertrauenswürdiger Ursprünge in Ihrer CORS-Konfiguration sowie serverseitige Token- oder Ursprungsvalidierung. CORS allein ist kein Schutz vor CSRF.

Es lohnt sich tatsächlich, diesen Pfad einem Penetrationstest zu unterziehen. Web-Scanner erkennen zwar die offensichtlichen CSRF-Lücken, doch es kann leicht vorkommen, dass das Cookie zwar korrekt gesetzt ist, die Validierung bei einer Untergruppe von Routen jedoch stillschweigend übersprungen wird.

4. Routenwächter und Berechtigungen sperren

Der Router von Angular ist leistungsstark, und genau deshalb sind Autorisierungsfehler hier so kostspielig – wenn auch nicht immer in der Weise, wie Teams davon ausgehen. Angular erzwingt keine Zugriffskontrolle; das liegt in Ihrer Verantwortung und der Ihres Backends.

Ein fehlender Schutz macht clientseitige Ansichten und Navigationspfade für jeden zugänglich, der die URL kennt. Zu einer Datenpanne kommt es, wenn auch die hinter diesen Ansichten stehende API keine Autorisierungsprüfung durchführt. Beide Aspekte sind von Bedeutung, und nur einer davon fällt in den Zuständigkeitsbereich von Angular.

Ein paar Dinge, die man beachten sollte:

• Jede geschützte Route benötigt einen Guard, und verlassen Sie sich nicht darauf, dass die Benutzeroberfläche Links zu nicht autorisierten Bereichen ausblendet. Modernes Angular verwendet funktionale Guards – CanActivateFn für die Navigation und canMatch für den Routenabgleich – anstelle der veralteten klassenbasierten Schnittstellen.
• Guards dürfen zwar den vom Server abgeleiteten Authentifizierungs- oder Berechtigungsstatus abfragen, dürfen jedoch keinesfalls die Autorisierungsprüfungen der API ersetzen. Ein Flag in „localStorage“ , das jeder Benutzer bearbeiten kann, stellt keine Zugriffskontrolle dar.
• Verwenden Sie canMatch bei verzögert geladenen Routen, damit der Router die Routenkonfiguration für nicht autorisierte Benutzer nicht abgleicht oder lädt.
• Prüfen Sie Guard-Ausdrücke explizit. Es ist üblich, einen Guard-Ausdruck zu haben, der true in Randfällen zurückgibt, obwohl dies nicht beabsichtigt ist.

Achtung: Lazy Loading ist kein Datenschutz. Route-Guards werden im Browser ausgeführt und steuern die Navigation; sie können niemanden daran hindern, ein öffentlich bereitgestelltes JavaScript-Bundle direkt abzurufen oder es in DevTools einzulesen. Speichern Sie niemals Geheimnisse, nicht veröffentlichte Endpunkte oder sensible Autorisierungslogik im clientseitigen Code – egal, ob dieser per Lazy Loading geladen wird oder nicht – und setzen Sie die Autorisierung bei jeder geschützten Backend-Anfrage durch.

 5. Behandeln Sie Skripte von Drittanbietern als Angriffsfläche

Jedes Skript eines Drittanbieters, das Sie laden – Analysetools, Chat-Widgets, A/B-Test-Tools, Werbenetzwerke –, wird mit denselben Berechtigungen ausgeführt wie Ihr eigener Code. Die Sanitisierung von Angular schützt Ihre Vorlagen, isoliert jedoch keine Skripte, die außerhalb dieser geladen werden.

Dies ist ein praktisches Problem, kein theoretisches. Im September 2025 führte ein Phishing-Angriff auf das Konto eines einzelnen npm-Betreuers dazu, dass Schadcode in 18 weit verbreitete Pakete eingeschleust wurde, darunter chalk und debug, die zusammen wöchentlich Milliarden von Downloads verzeichnen. Tage später sammelte der sich selbst replizierende Shai-Hulud-Wurm Anmeldedaten von Entwicklern und verbreitete sich im gesamten Repository; GitHub entfernte mehr als 500 kompromittierte Pakete, und die CISA gab eine Warnung heraus. Der OSSRA-Bericht von 2026 verdeutlicht dieses Muster: Von den bösartigen Paketen, die Black Duck in Open-Source-Ökosystemen identifiziert hat, wurden 66 % gezielt entwickelt, um durch Taktiken wie Typosquatting und Verwirrung bei den Abhängigkeiten Schaden anzurichten, während 34 % legitime Pakete waren, die gekapert wurden, nachdem sie das Vertrauen der Community gewonnen hatten.

Einige Steuerelemente, deren Implementierung sich lohnt:

1. Subresource Integrity (SRI) führt Hash-Berechnungen für extern gehostete Skripte mit stabilen, versionierten Inhalten durch. Wenn die abgerufene Datei nicht mehr mit dem angegebenen Hash übereinstimmt, weigert sich der Browser, sie auszuführen. Damit SRI funktioniert, ist außerdem eine entsprechende CORS-Konfiguration auf dem Host erforderlich.
2.  CSP-Regeln, die Ursprünge von Drittanbietern ausdrücklich zulassen, anstatt * oder „unsafe-inline“.
3. Regelmäßige Überprüfungen, welche Skripte von Drittanbietern in der Produktionsumgebung geladen werden. Marketing- und Analysetools häufen sich im Laufe der Zeit an und ziehen oft ihre eigenen Unterabhängigkeiten mit sich.
4. Soweit möglich, sollten Bibliotheken von Drittanbietern selbst gehostet und fest eingebunden werden. Dadurch wird das CDN aus Ihrer Vertrauenskette entfernt, allerdings liegt die Verantwortung für die Bereitstellung von Patches dann bei Ihrem Team. Kombinieren Sie dies daher mit einem Prozess zur Nachverfolgung von Upstream-Korrekturen.

6. Halten Sie Angular und seine Abhängigkeiten auf dem neuesten Stand

Das Aufbringen von Patches ist eine Maßnahme, die Teams so lange aufschieben, bis daraus eine Migration wird. Führen Sie folgenden Befehl aus: npm audit in der CI aus und sortieren Sie die Ergebnisse tatsächlich nach Priorität, anstatt die Warnungen zu ignorieren, nur weil es keinen sofortigen Lösungsweg gibt. Betrachten Sie es als einen Anhaltspunkt und nicht als vollständige Bewertung: Es meldet bekannte Sicherheitshinweise zu den in Ihren Manifesten und Lockfiles deklarierten Paketen, und die OSSRA-Studie von 2026 ergab, dass 17 % der Open-Source-Komponenten überhaupt nicht über Standard-Paketmanager in den Code gelangen – per Copy-Paste eingefügte Code-Schnipsel, Vendor-Code, KI-generierter Code –, wo manifestbasierte Scanner sie niemals erkennen.

Derselbe Bericht zitiert eine separate Black-Duck-Umfrage aus dem Jahr 2025, in der 65 % der befragten Unternehmen angaben, einen Angriff auf die Software-Lieferkette im vergangenen Jahr erlebt hätten. Diese Zahl sollte man sich vor Augen führen: Angriffe auf die Lieferkette sind kein Randphänomen mehr, sondern ein weit verbreitetes Problem für Unternehmen. Von den geprüften Codebasen enthielten 87 % mindestens eine bekannte Open-Source-Sicherheitslücke und 78 % mindestens eine Sicherheitslücke mit hohem Risiko.

npm audit   ng update @angular/core @angular/cli

 Halten Sie sich an das unterstützte Release-Fenster von Angular, automatisieren Sie Pull-Requests für Abhängigkeiten mit Dependabot oder Renovate und nehmen Sie transitive CVEs ernst, auch wenn noch keine direkte Behebung verfügbar ist. Eine Sicherheitslücke kann auch mehrere Ebenen tiefer im Abhängigkeitsbaum ausgenutzt werden. Prüfen Sie daher, ob Ihre Anwendung den anfälligen Code tatsächlich erreicht, anstatt ihn als indirekt abzutun.

Die schwierigere Variante dieses Problems ergibt sich, wenn ein Upgrade nicht möglich ist. Eine Migration auf eine neue Hauptversion kann kostspielig sein, die Anwendung läuft stabil, und es ist schwer, die wirtschaftlichen Argumente für eine Neuprogrammierung zu finden. Genau hier entsteht die EOL-Lücke.

Tools und Lösungen für die Angular-Sicherheit

Die Absicherung von Angular ist keine einmalige Maßnahme. Sie umfasst die fortlaufende Bereitstellung von Patches, die Überwachung von Sicherheitslücken und den Support. Die meisten Teams benötigen dafür mehr als ein Tool.

Lösung	Was ist abgedeckt?	Am besten geeignet für
Snyk / Dependabot / npm-Prüfung	Bekannte Sicherheitshinweise, die sich auf in Manifesten und Lockfiles deklarierte Abhängigkeiten auswirken – sowohl direkte als auch transitive	Teams, die aktiv Releases veröffentlichen, CI-integriert
CSP, Trusted Types und ZAP	Absicherung gegen Laufzeit-XSS und Scannen auf Anwendungsebene	Sicherheitsorientierte Teams, die die Produktionsumgebung absichern
TuxCare Endless Lifecycle Support (ELS) für OSS	Rückwärtskompatible Patches für das nicht mehr unterstützte Angular (Versionen 4 bis 19) und die damit kompatiblen Abhängigkeiten, bereitgestellt über npm	Teams, die an nicht mehr unterstützten Versionen festhängen und auditfähige Software benötigen, ohne dass eine Neuprogrammierung erzwungen wird

 Abhängigkeits-Scanner (Snyk, Dependabot, npm audit)

Tools zur Software-Kompositionsanalyse (SCA) überwachen Ihren Abhängigkeitsbaum und kennzeichnen bekannte CVEs, auch in Paketen, die Sie nie direkt installiert haben. Snyk und Dependabot von GitHub leisten hier gute Arbeit, und „npm audit“ ist kostenlos im Lieferumfang von npm enthalten. Snyk unterhält eine umfangreiche kommerzielle Schwachstellendatenbank, und die automatisierten Pull-Requests von Dependabot erleichtern es, stets auf dem neuesten Stand zu bleiben. Ideal für aktive Entwicklungsteams, die die CVE-Erkennung vor dem Zusammenführen von Code in die CI integrieren möchten.

Laufzeit-Absicherung

Abhängigkeitsscanner erkennen bekannte Probleme in Paketen. Sie erkennen jedoch weder eine fehlende Content Security Policy noch einen ausnutzbaren DOM-Schreibzugriff in Ihrem eigenen Code. Tools für dynamische Anwendungssicherheitstests (DAST) – darunter der Open-Source-Zed Attack Proxy, ehemals OWASP ZAP und nun von Checkmarx als ZAP gepflegt – testen die laufende Anwendung auf Injektionsschwachstellen, schwache Header und CSRF-Lücken. Ideal für sicherheitsbewusste Teams, die eine Produktionsanwendung absichern und nicht nur Pakete prüfen.

Der unbegrenzte Lebenszyklus-Support von TuxCare für Angular

Die größte Lücke, die es zu schließen gilt, ist die EOL-Lücke. Wenn für Ihre Angular-Version keine Updates mehr bereitgestellt werden und eine Migration nicht in absehbarer Zeit geplant ist, werden Scanner weiterhin Probleme melden, die Sie nicht über offizielle Kanäle beheben können.

Das moderne Angular beseitigt dieses Problem nicht, sondern verschiebt lediglich den Stichtag. Für jede Hauptversion läuft der Support irgendwann aus, und sobald dies geschieht, hat sie keinen Anspruch mehr auf routinemäßige Sicherheitsupdates aus dem Upstream. TuxCare portiert Sicherheitsupdates auf nicht mehr unterstützte Framework-Versionen und die davon abgedeckten Abhängigkeiten zurück.

Angular-Versionen 4 bis 19 haben alle ab Mitte 2026. Falls Ihr Team eine dieser Versionen einsetzt und kein Upgrade innerhalb kurzer Zeit durchführen kann, bietet der „Endless Lifecycle Support für Angular“ von TuxCare bietet fortlaufende Sicherheitspatches über npm – denselben Paketmanager, den Ihr Team bereits nutzt. Der Umfang umfasst die zentralen Angular-Pakete, auf denen Ihre App basiert – @angular/core, @angular/platform-browser, @angular/common, @angular/router, @angular/forms, @angular/cli, @angular/compiler, @angular/compiler-cliund @angular/platform-browser-dynamic – sowie deren unterstützte Abhängigkeiten, ohne zusätzliche Kosten.

Der praktische Vorteil liegt auf der Hand: Sie sind weiterhin abgesichert, während Sie das Upgrade nach Ihrem eigenen Zeitplan planen, anstatt eine überstürzte Migration durchzuführen, um eine Sicherheitsprüfung zu ermöglichen.

Angular mit TuxCare absichern

Angular bietet Ihnen eine solide Ausgangsbasis, schützt jedoch nur bestimmte Teile der clientseitigen Anwendung. Der Rest liegt bei Ihrem Team: konsequente Datenbereinigung, CSP und Trusted Types, XSRF-Konfiguration auf beiden Seiten, Routenautorisierung mit serverseitigen Überprüfungen, Kontrolle von Skripten von Drittanbietern sowie das Patchen von Abhängigkeiten.

Was die meisten Teams unterschätzen, ist, was nach einer Angular-Version das Ende ihres Lebenszyklus erreicht hat und keine offiziellen Korrekturen mehr bereitgestellt werden. Genau diese Lücke füllt der „Endless Lifecycle Support“ von TuxCare ausfüllen soll

TuxCare deckt mehr als nur Angular ab. Wenn Ihr Stack nicht unterstützte Versionen anderer JavaScript-Frameworks oder -Bibliotheken enthält – wie React, Vue, AngularJS, jQuery, Next.js, Express und andere –, bietet TuxCare auch hierfür Support an. Die aktuelle Abdeckung finden Sie unter Unbegrenzter Lebenszyklus-Support für Bibliotheken und Frameworks.

 

FAQs