Bezpieczeństwo w Angular — wszystko, co powinien wiedzieć developer

Bezpieczeństwo to jedna z najważniejszych kwestii współczesnego świata IT. W czasach, gdy dane, know-how czy kod aplikacji mogą być warte miliony dolarów, ochrona systemów przestaje być dodatkiem, a staje się koniecznością. Czy jako Angular deweloperzy musimy zwracać na to szczególną uwagę? Czy tak rozbudowany i zaawansowany framework jak Angular zrobi wszystko za nas?

W tym artykule przedstawię najważniejsze zagrożenia, które mogą dotyczyć aplikacji Angular, oraz odniosę się do ostatnich podatności wykrytych zarówno w samym Angularze, jak i w bibliotekach publikowanych w ekosystemie npm.

Angular często uchodzi za bezpieczny framework out of the box i rzeczywiście oferuje wiele mechanizmów ochronnych. Problem pojawia się wtedy, gdy sami decydujemy się je wyłączyć.

Najczęstsze zagrożenia bezpieczeństwa w aplikacjach Angular

XSS

Cross-Site Scripting to najczęstszy i najgroźniejszy atak w aplikacjach typu SPA i jednocześnie taki, który Angular aktywnie próbuje powstrzymać. Na szczęście, domyślnie nasze templatki są bezpieczne. To znaczy, że bindingi i interpolacje w naszych templatkach są automatycznie enkodowane.

Enkodowanie HTML – co to znaczy?

Enkodowanie HTML oznacza zamianę znaków, które mają szczególne znaczenie w HTML, takich jak <, > czy ’, na ich bezpieczne odpowiedniki w postaci encji HTML. Dzięki temu przeglądarka traktuje je jako zwykły tekst, a nie jako kod do wykonania.

Na przykład kod:

<script>console.error('I caught you!')</script>

zostanie wyrenderowany jako:

<script>console.error('I caught you!')</script>

Czyli:

• < zamieniane jest na &lt;
• > zamieniane jest na &gt;
• ’ zamieniane jest na &#39;

W efekcie przeglądarka wyświetli tekst, ale nie wykona zawartego w nim kodu.

Warto jednak doprecyzować, że takie enkodowanie zachodzi tylko wtedy, gdy Angular wyświetla tekst poprzez interpolację lub innerText. W przypadku innerHTML Angular próbuje wyrenderować HTML, dlatego zamiast enkodowania stosuje mechanizm sanityzacji.

Poniższy przykład komponentu pokazuje różnicę:

import { Component } from '@angular/core';


@Component({
 selector: 'app-xss-demo',
 template: `
   <h3>Interpolacja</h3>
   <div>{{ jsCode }}</div>
   <h3>innerText</h3>
   <div [innerText]="jsCode"></div>
   <h3>innerHTML</h3>
   <div [innerHTML]="jsCode"></div>
 `
 })
export class XssDemoComponent {


readonly jsCode = `<script>console.error('I caught you!')</script>
<img src="x" onerror="alert('XSS')">`;


}

W pierwszych dwóch przypadkach ({{ }} oraz innerText) Angular zastosuje enkodowanie HTML, dzięki czemu kod zostanie wyświetlony jako zwykły tekst.

Natomiast przy innerHTML Angular spróbuje wyrenderować HTML, ale najpierw uruchomi mechanizm sanityzacji. Oznacza to, że niebezpieczne elementy, takie jak <script> czy atrybuty onerror, zostaną usunięte. W trybie developerskim Angular dodatkowo wyświetli ostrzeżenie w konsoli informujące o usunięciu niebezpiecznej zawartości.

Problem zaczyna się w momencie, gdy w aplikacji pojawia się surowy HTML, na przykład z edytora WYSIWYG, opisu produktu czy komentarza. W takich sytuacjach często niepotrzebnie używany jest DomSanitizer.bypassSecurityTrustHtml, bypassSecurityTrustStyle czy bypassSecurityTrustUrl.

Metody te w praktyce wyłączają mechanizmy bezpieczeństwa Angulara i oznaczają: „zaufaj mi, wiem co robię”. Najczęściej stosuje się je jako szybkie rozwiązanie problemu z usuwanymi atrybutami, iframe czy obrazami.

Zamiast omijać mechanizmy bezpieczeństwa, lepszym podejściem jest kontrolowanie tego, co dokładnie może trafić do DOM. W praktyce oznacza to wprowadzenie jasnych reguł dotyczących dopuszczalnych elementów i atrybutów HTML. Jeśli w treści potrzebne są osadzenia wideo, można dopuścić iframe, ale tylko dla wybranych domen (np. konkretnych serwisów) oraz z ograniczoną listą bezpiecznych atrybutów. W przypadku obrazów warto kontrolować img src i dopuszczać wyłącznie zaufane źródła, takie jak własny CDN lub określone domeny.

Podobnie z adresami – zamiast oznaczać każdy link jako zaufany przy użyciu bypassSecurityTrustUrl, lepiej walidować URL-e: sprawdzać protokół (np. dopuszczać tylko https:) oraz ewentualnie ograniczać domeny, z których mogą pochodzić zasoby. Dzięki temu nawet jeśli treść pochodzi z zewnętrznego źródła, nadal zachowujemy kontrolę nad tym, jakie zasoby są ładowane i jakie elementy mogą zostać wyrenderowane w aplikacji.

Takie podejście pozwala zachować funkcjonalność edytorów treści i dynamicznego HTML-a, a jednocześnie utrzymać realne mechanizmy ochrony przed wstrzyknięciem niebezpiecznego kodu w przeglądarce.

XSS w Angularze rzadko jest błędem frameworka. Najczęściej wynika ze świadomej decyzji dewelopera, który chciał „tylko wyświetlić HTML”.

Warto podkreślić, że [innerHTML] samo w sobie nie jest niebezpieczne. Angular domyślnie sanityzuje HTML wstawiany w ten sposób.

Sanityzacja polega na usunięciu lub zneutralizowaniu niebezpiecznych fragmentów HTML przed ich interpretacją przez przeglądarkę. Spójrzmy na prosty przykład komponentu Angularowego:

import { Component } from '@angular/core';


@Component({
 selector: 'app-article',
 template: `
  <h2>Treść artykułu</h2>
  <div [innerHTML]="content"></div>
`
 })
export class ArticleComponent {
content = `
<p>Super artykuł!</p>
<script>alert('XSS')</script>
`;
}

Angular przed wyrenderowaniem treści wykona sanityzację. HTML:

<p>Super artykuł!</p>
<script>alert('XSS')</script>

zostanie przekształcony do bezpiecznej postaci:

<p>Super artykuł!</p>

Tag <script> zostanie usunięty i kod JavaScript nie zostanie wykonany. Oprócz tego mechanizm sanityzacji Angulara usuwa również event handlery (onclick, onerror), blokuje protokoły takie jak javascript: w URL-ach oraz czyści podejrzane atrybuty, które mogłyby prowadzić do wykonania złośliwego kodu.

Warto jednak pamiętać, że Angular nie traktuje wszystkich wartości tak samo. Framework rozróżnia tzw. security contexts, czyli konteksty bezpieczeństwa, w których dana wartość jest używana. To właśnie kontekst decyduje o tym, w jaki sposób Angular przeprowadzi sanityzację.

Najważniejsze z nich to:

• HTML – gdy interpretujesz wartość jako HTML (np. [innerHTML]).
• Style – gdy wartość trafia do stylów CSS (np. [style] lub style=””).
• URL – gdy przypisujesz adres do właściwości takich jak href czy src.
• Resource URL – gdy URL wskazuje na zasób, który może zostać wykonany jako kod (np. zewnętrzny skrypt lub niektóre osadzone zasoby).
  

To tłumaczy, dlaczego Angular czasem usuwa fragmenty treści, które na pierwszy rzut oka wydają się nieszkodliwe – sanityzacja jest dopasowana do konkretnego kontekstu użycia.

W praktyce oznacza to, że zamiast omijać mechanizmy bezpieczeństwa przy pomocy bypassSecurityTrust…, lepiej kontrolować dane zależnie od miejsca ich użycia. Przykładowo:

• walidować URL-e zamiast oznaczać je jako zaufane,
• kontrolować img src i dopuszczać tylko bezpieczne źródła,
• dopuszczać iframe tylko dla wybranych domen i z ograniczoną listą dozwolonych atrybutów.
  

Dzięki temu zachowujemy funkcjonalność dynamicznych treści, jednocześnie nie rezygnując z wbudowanych mechanizmów bezpieczeństwa Angulara.

Tokeny i autoryzacja

Angular może zarządzać stanem uwierzytelnienia użytkownika w aplikacji, jednak należy pamiętać, że aplikacja frontendowa działająca w przeglądarce nie jest bezpiecznym miejscem do przechowywania wrażliwych danych, takich jak długoterminowe tokeny czy klucze API.

Cały kod oraz przechowywane dane są dostępne po stronie klienta, dlatego należy zakładać, że potencjalny atakujący może mieć do nich dostęp. Z tego powodu wrażliwe operacje i sekrety powinny być przechowywane oraz obsługiwane po stronie backendu, a frontend powinien operować wyłącznie na krótkotrwałych tokenach lub identyfikatorach sesji.

Najczęstsze problemy:

• Access token w localStorage – jeden skuteczny XSS i token może zostać odczytany oraz użyty poza aplikacją.
• Interceptory doklejające token do każdego requestu – ryzyko wysłania go do zewnętrznych domen lub niezamierzonych endpointów.
• Poleganie wyłącznie na ukrywaniu elementów po stronie frontu i na route guardach – frontend może ukryć widok, ale nie powinien decydować o dostępie do danych.
  

Wniosek z tego jest jeden. Każda decyzja o dostępie musi zostać potwierdzona po stronie serwera – inaczej to tylko iluzja bezpieczeństwa.

Jakie ryzyka wiążą się z przechowywaniem tokenu w przeglądarce? 

Wybór miejsca przechowywania tokenu w przeglądarce zawsze wiąże się z pewnymi ryzykami – nie ma idealnego sposobu, więc finalny wybór powinien zależeć od indywidualnego przypadku każdej aplikacji. 

Token w localStorage lub sessionStorage

Implementacja tego rozwiązania jest bardzo prosta. Z pewnością, tworząc nowy projekt, spotkaliście się z takim rozwiązaniem. Najczęściej state użytkownika/auth jest synchronizowany z kluczem w local/session storage. Nie jest to jednak rozwiązanie bez wad. Jest bardzo podatny na XSS. Token przechowywany jest jawnie (każdy może go sprawdzić i skopiować), a co za tym idzie, może użyć go poza przeglądarką.

Cookies z flagą HttpOnly

W tym rozwiązaniu token nie jest jawny. Nie możemy zobaczyć go z poziomu przeglądarki ani odczytać za pomocą JavaScriptu więc rozwiązanie jest odporne na XSS. Natomiast, cookie jest wysyłany automatycznie w każdym requeście więc pojawia się ryzyko związane z CSRF. Oczywiście, takie cookie trzeba poprawnie skonfigurować. Musi to być cookie HttpOnly, czyli niedostępny do odczytu z poziomu przeglądarki. Należy także poprawnie skonfigurować atrybuty Secure i SameSite.

CSP

Content Security Policy to jedno z najpotężniejszych narzędzi ochrony aplikacji webowych i jednocześnie jedno z najrzadziej konfigurowanych. Dobrze ustawione CSP potrafi zablokować skutki XSS nawet wtedy, gdy błąd już istnieje w kodzie aplikacji. Ogranicza to, skąd aplikacja może ładować skrypty, style i obrazy, a jednocześnie zmusza do rezygnacji z niebezpiecznych mechanizmów takich jak inline JavaScript czy eval. CSP konfigurowane jest poprzez nagłówek HTTP Content-Security-Policy.

Jeśli nie miałeś wcześniej styczności z tym mechanizmem, warto zapoznać się z dokumentacją, która szczegółowo opisuje wszystkie dostępne dyrektywy i sposób ich działania:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

W praktyce CSP działa jak druga bariera: nawet jeśli atakujący wstrzyknie <script>, przeglądarka po prostu odmówi jego wykonania.

Specyfika CSP w Angularze

Angular generuje część kodu i stylów dynamicznie. Style zdefiniowane w komponentach są w trakcie działania aplikacji wstrzykiwane do dokumentu w postaci znaczników <style>. W praktyce oznacza to, że Angular może dodawać kolejne style lub modyfikować atrybuty DOM w odpowiedzi na zmiany stanu aplikacji. W trybie deweloperskim wykorzystywane są dodatkowo mechanizmy wspierające source maps oraz Hot Module Replacement.

Z tego powodu konfiguracja CSP musi uwzględniać możliwość wykonywania skryptów i stylów oznaczonych odpowiednim nonce, zamiast polegać na niebezpiecznym unsafe-inline, które pozwala na wstawienie dowolnego kodu JavaScript lub CSS.

Nonce dla skryptów i stylów

Konfiguracja CSP w Angularze często opiera się na mechanizmie nonce, czyli losowym identyfikatorze generowanym przy każdym żądaniu. Identyfikator ten jest następnie dodawany zarówno do nagłówka CSP, jak i do tagów <script> oraz <style> w dokumencie HTML.

Przykładowy nagłówek może wyglądać następująco:

Content-Security-Policy:
 script-src 'self' 'nonce-generatedNonce';
 style-src 'self' 'nonce-generatedNonce';

Nonce musi być generowany po stronie serwera, wstrzyknięty do nagłówka Content-Security-Policy oraz dodany do odpowiednich elementów w HTML. W Angularze można to zrealizować między innymi poprzez token CSP_NONCE lub atrybut ngCspNonce.

Jeśli chcesz lepiej zrozumieć, dlaczego nonce jest tak ważne i czym różni się tzw. strict CSP od klasycznych konfiguracji opartych na allowlistach domen, warto zajrzeć do artykułu:
https://web.dev/articles/strict-csp

Mechanizm ten polega na tym, że przeglądarka wykonuje tylko te skrypty lub style, które mają poprawny atrybut nonce zgodny z wartością w nagłówku CSP. Dzięki temu nawet jeśli w aplikacji pojawi się luka pozwalająca wstrzyknąć HTML, atakujący nie będzie w stanie uruchomić własnego kodu bez znajomości poprawnej wartości nonce.

Oczywiście będzie to wymagało też dodatkowej konfiguracji na serwerze produkcyjnym, na przykład w Nginxie.

Dlaczego jest to ważne?
Angular (szczególnie w trybie produkcyjnym) może generować lub modyfikować style dynamicznie. Bez nonce często kończy się to wymuszeniem unsafe-inline, co osłabia ochronę.

Nonce pozwala uniknąć unsafe-inline i nadal umożliwia działanie aplikacji.

Angular i Trusted Types

Angular wspiera również Trusted Types enforcement, czyli mechanizm przeglądarki ograniczający możliwość wstrzykiwania niebezpiecznych stringów do API takich jak innerHTML, insertAdjacentHTML czy eval.

W praktyce CSP może zawierać:

require-trusted-types-for 'script';
trusted-types angular angular#bundler;

To powoduje, że przeglądarka odrzuci próby wstrzyknięcia nieautoryzowanego HTML/JS nawet jeśli ktoś ominie sanityzację w kodzie.

Minimalna praktyczna konfiguracja dla Angular SPA

Dla nowej aplikacji Angular warto rozważyć przynajmniej taką konfigurację nagłówka CSP:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<dynamic>';
  style-src 'self' 'nonce-<dynamic>';
  img-src 'self' https:;
  connect-src 'self' https://api.twojadomena.pl;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  require-trusted-types-for 'script';

Na pierwszy rzut oka konfiguracja może wydawać się rozbudowana, jednak każda z tych dyrektyw ogranicza konkretny typ zasobu, który przeglądarka może załadować lub wykonać. script-src i style-src kontrolują źródła skryptów i stylów, img-src określa skąd mogą być ładowane obrazy, a connect-src ogranicza adresy API, z którymi aplikacja może się komunikować. Dyrektywy takie jak object-src, base-uri czy frame-ancestors dodatkowo blokują rzadziej używane, ale potencjalnie niebezpieczne mechanizmy przeglądarki. Dzięki temu nawet jeśli w aplikacji pojawi się luka bezpieczeństwa, przeglądarka będzie mogła zablokować część prób jej wykorzystania.

Oczywiście konkretne wartości zależą od używanych CDN-ów, narzędzi do analityki czy iframe. Najważniejsze jest jednak unikanie:

• ’unsafe-inline’
• ’unsafe-eval’

Dlaczego CSP to „ostatnia linia obrony”? Bo działa wtedy, gdy wszystko inne zawiedzie:

• jeśli pojawi się nieznana luka XSS,
• jeśli ktoś użyje bypassSecurityTrust*(),
• jeśli jakaś biblioteka wprowadzi podatność,
• jeśli sanityzacja okaże się niewystarczająca.

Ostatnie podatności w Angularze

Choć Angular oferuje wiele mechanizmów bezpieczeństwa, takich jak automatyczna sanitizacja HTML czy ochrona przed XSS, nie oznacza to, że framework sam w sobie gwarantuje pełne bezpieczeństwo aplikacji. Właśnie dlatego tak ważne są dodatkowe mechanizmy ochronne, takie jak CSP czy poprawna walidacja danych po stronie serwera.

Ostatnie podatności opublikowane przez zespół Angulara dobrze pokazują, dlaczego nie warto bezgranicznie polegać na zabezpieczeniach frameworka. Nawet dojrzałe i szeroko używane narzędzia mogą zawierać błędy, szczególnie w mniej oczywistych obszarach, takich jak sanitizacja SVG, heurystyki rozpoznawania pochodzenia żądań HTTP czy mechanizmy renderowania po stronie serwera.

W praktyce oznacza to, że nawet jeśli aplikacja została napisana zgodnie z dobrymi praktykami, a Angular wykonuje część pracy za nas, nadal mogą istnieć scenariusze, w których luka w samym frameworku pozwala ominąć jego mechanizmy ochronne. W takich sytuacjach dodatkowe warstwy zabezpieczeń, na przykład CSP, mogą ograniczyć skutki potencjalnego ataku.

Poniżej znajdują się przykłady kilku podatności, które w ostatnim czasie zostały wykryte w Angularze.

SSR: Race Condition – Cross-Request Data Leakage

Źródło: https://github.com/angular/angular/security/advisories/GHSA-68×2-mx4q-78m7

Na czym polegała podatność:
Błąd w Angular Server-Side Rendering (SSR) polegający na współdzieleniu globalnego „platform injector”, co tworzyło race condition między równoległymi requestami. Jeśli serwer SSR renderował dwa żądania jednocześnie, część danych z jednego mogła niepoprawnie trafić do odpowiedzi drugiego.

Możliwe konsekwencje:

• możliwy wyciek danych między użytkownikami,
• np. fragmenty odpowiedzi, tokeny albo treści prywatne mogą pojawić się w części innego użytkownika,
• to nie XSS/CORS, tylko błąd logiczny w serwerowym renderowaniu.
  

XSRF Token Leakage przez URL-e

Źródło: https://github.com/angular/angular/security/advisories/GHSA-58c5-g7wp-6w37

Na czym polegała podatność:
HttpClient Angulara próbował określić, czy dany request jest same-origin, bazując na obecności protokołu (http://, https://). Jednak URL-y zaczynające się od // (tzw. protocol-relative) były błędnie uznawane za same-origin, więc Angular dorzucał do nich nagłówek X-XSRF-TOKEN.

Możliwe konsekwencje:

• XSRF token był wysyłany nawet do obcych domen
• ktoś mógł przechwycić token i potem wykonać fałszywe POST/DELETE/PUT w imieniu użytkownika – czyli klasyczny CSRF.
  

Stored XSS przez SVG / MathML atrybuty

Źródło: https://github.com/angular/angular/security/advisories/GHSA-v4hv-rgfq-gp49

Na czym polegała podatność:
Błąd w Angular Template Compiler, który nieprawidłowo klasyfikował niektóre atrybuty SVG i MathML związane z URL-ami – np. xlink:href, math|href albo attributeName w animacji SVG.

Mechanizm ataku:

• jeśli aplikacja wiązała dane użytkownika właśnie do tych atrybutów (np. [attr.xlink:href]=”…”),
• a wartość była złośliwa (np. javascript: URL),
• Angular mógł nie zastosować sanityzacji i pozwolić, by ten URL został wstrzyknięty.
  

Skutek:
Możliwy Stored XSS czyli złośliwy kod mógł się wykonywać po interakcji użytkownika (np. kliknięciu) lub automatycznie przez animację SVG.

XSS przez nieznane SVG <script> atrybuty

Źródło: https://github.com/angular/angular/security/advisories/GHSA-jrmj-c5cx-3cw6

Na czym polegała podatność:
Kolejny błąd w sanityzacji Angulara dotyczący wewnętrznej polityki bezpieczeństwa: Angular nie klasyfikował href i xlink:href w elementach <script> wewnątrz SVG jako kontekstów wymagających Resource URL sanityzacji.

Możliwe konsekwencje:

• jeśli ktoś użył [attr.href] na <svg><script>,
• Angular mógł potraktować wartość jak zwykły tekst,
• a atrybut mógł zawierać np. data:text/javascript,…, co prowadzi do uruchomienia JavaScript.
  

To również XSS, ale przez inny wektor SVG – różni się od poprzedniej luki głównie tym, który element/atrybut był źle klasyfikowany.

Podatności w NPM

Warto też wspomnieć o innym rodzaju zagrożenia, które nie dotyczy samego kodu aplikacji, ale zewnętrznych zależności pobieranych na przykład z NPM. Niedawno miały miejsce poważne ataki na ekosystem npm, w których złośliwe wersje popularnych pakietów zostały opublikowane w rejestrze i mogły być instalowane jak normalne zależności.

Przykładem jest kampania opisana w artykule S1ngularity/Nx attackers strike again, będąca częścią ataku znanego jako Shai-Hulud – samoreplikującego się worma działającego w ekosystemie npm. Zainfekowane pakiety zawierały malware zdolny do wykradania tokenów (np. z plików .npmrc) oraz innych poufnych danych środowiskowych, takich jak tokeny dostępu, klucze API czy zmienne środowiskowe. Po przejęciu tokenu atakujący mógł publikować zmodyfikowane wersje kolejnych bibliotek w imieniu ich twórców. W efekcie infekcja nie była jednorazowa – rozprzestrzeniała się dalej w łańcuchu zależności, „zarażając” kolejne paczki i projekty.

Kompletną listę dotkniętych bibliotek można znaleźć pod tym adresem:
https://www.aikido.dev/blog/s1ngularity-nx-attackers-strike-again

Tego typu supply-chain compromise pokazuje, że jeśli odpowiednie biblioteki zostaną zainfekowane i nie śledzisz na bieżąco stanu zależności, zagrożona może być nie tylko pojedyncza aplikacja, ale potencjalnie ogromna część internetu, która tych pakietów używa – zarówno w projektach klienckich, jak i w narzędziach deweloperskich czy pipeline’ach CI.

Jak radzić sobie z podatnościami

Aby ograniczyć ryzyko związane z podatnościami w frameworkach i zależnościach npm, kluczowe jest aktywne śledzenie informacji o bezpieczeństwie oraz szybka reakcja na opublikowane poprawki. W praktyce oznacza to regularne monitorowanie security advisories (np. GitHub Security Advisories), subskrybowanie komunikatów zespołów utrzymujących krytyczne biblioteki oraz korzystanie z narzędzi automatycznie analizujących zależności projektu. Do najczęściej stosowanych rozwiązań należą m.in. npm audit, GitHub Dependabot, Snyk, Aikido Security czy OWASP Dependency-Check – narzędzia te potrafią wykrywać znane podatności zarówno w bezpośrednich, jak i pośrednich zależnościach, a często także sugerować bezpieczne wersje aktualizacji. 

Sama identyfikacja problemu to jednak dopiero połowa drogi. Równie istotne jest możliwie szybkie aktualizowanie paczek po opublikowaniu poprawki, zanim luka zostanie masowo wykorzystana. Dobrym przykładem są ostatnie podatności w Angularze, które zostały naprawione dopiero od wersji 19.

Angular utrzymuje wsparcie jedynie dla ograniczonej liczby wersji wstecz, dlatego projekty korzystające ze starszych wydań mogą nie otrzymywać poprawek dla nowych podatności. W praktyce oznacza to, że aplikacje pozostające na nieaktualnych wersjach frameworka mogą być narażone na znane luki bezpieczeństwa, nawet jeśli ich autorzy są ich świadomi.

W takiej sytuacji brak aktualizacji nie jest neutralną decyzją techniczną, lecz realnym i rosnącym ryzykiem zarówno dla bezpieczeństwa aplikacji, jak i dla całego projektu.