← Wszystkie tematy W 26% ogłoszeń · 12 z 47 ogłoszeń frontend React

Bezpieczeństwo i prywatność

Zamek w drzwiach i nieufny portier

Bezpieczeństwo i prywatność pojawiają się w 12 z 47 ogłoszeń, częściej w fintechu i bankach. Na rozmowie padają klasyki: XSS, gdzie trzymać token, CSRF i logowanie przez OAuth.

Przerobione Opanowane 0 z 5 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Dbanie o jakość, bezpieczeństwo, czytelność i łatwość utrzymania kodu.”
Upvanta sp. z o.o. · Front-End Engineer (React / TypeScript / AWS)
„Knowledge of web accessibility standards, front-end security practices, and performance optimisation.”
Capco Poland · Front-End Engineer - React (Payments)
„Platforma oferuje szeroki wybór pakietów ubezpieczeniowych, benefitów i usług, które wpływają na komfort pracy, bezpieczeństwo i rozwój zawodowy.”
Pekao CoNext · Programista Frontend / Senior

Scena pierwsza · XSS

Nieufny portier

Na tablicy w przedszkolu każdy może przypiąć karteczkę. Większość pisze „fajny lizak!”, ale ktoś może przypiąć karteczkę z instrukcją dla robota: „otwórz szafkę i oddaj mi klucze”. Nieufny portier czyta każdą karteczkę jako zwykły tekst i nigdy nie wykonuje poleceń z niej. Wybierz komentarz i sposób wyświetlania.

Fajny lizak! <b>Super</b> lizak <img src=x onerror="ukradnij()">

Tablica z komentarzami

{komentarz} dangerouslySetInnerHTML DOMPurify

Scena druga · gdzie trzymać token

Klucz pod wycieraczką czy w sejfie?

Po zalogowaniu dostajesz klucz (token). Możesz go schować pod wycieraczką (localStorage): każdy skrypt na stronie go znajdzie. Albo oddać do sejfu, który otwiera tylko listonosz (ciasteczko httpOnly): przeglądarka sama dołącza je do zapytań, ale JavaScript go nie widzi. Wpuść złodzieja.

token: eyJhbGci…

Skrypt złodziejaczeka

localStorage cookie httpOnly

Wybierz schowek i wpuść złodzieja.

Porównajmy

XSS czy CSRF?

	XSS	CSRF
Co się dzieje?	Obcy wkłada swoją instrukcję do Twojego domu.Wstrzyknięty skrypt działa na Twojej stronie z prawami użytkownika.	Obca strona namawia przeglądarkę, żeby wysłała list w Twoim imieniu.Żądanie z innej domeny korzysta z ciasteczek zalogowanego użytkownika.
Skąd się bierze?	Z tekstu od użytkownika pokazanego jako HTML.`dangerouslySetInnerHTML`, `innerHTML`, `href="javascript:"`, biblioteki bez escapowania.	Z ciasteczek, które przeglądarka dołącza sama.Formularz lub obrazek na złej stronie wysyła POST do Twojego API.
Obrona	Czytaj karteczki jako tekst.Escapowanie (React robi to domyślnie), DOMPurify, Content-Security-Policy.	Sprawdzaj, kto przyniósł list.`SameSite=Lax/Strict`, token CSRF, sprawdzanie nagłówka Origin.
Co kradnie?	Wszystko, co widzi JS.Token z localStorage, dane z ekranu, akcje w imieniu użytkownika.	Nic nie czyta, tylko wykonuje akcję.Przelew, zmiana maila, usunięcie konta.
Pytanie na rozmowie	„Czy React chroni przed XSS?”Tak przy `{tekst}`, nie przy innerHTML, linkach javascript: i SSR bez escapowania.	„Co daje SameSite?”Ciasteczko nie leci przy żądaniach z cudzej strony (Lax domyślnie w Chrome).

Karteczka to tekst

Tego, co napisał użytkownik, nigdy nie wstawiaj jako HTML bez czyszczenia.

Sejf, nie wycieraczka

Token w ciasteczku httpOnly jest niewidoczny dla skryptów. W localStorage widzi go każdy.

Kilka zamków

Escapowanie, CSP, SameSite i walidacja na serwerze. Jeden zamek to za mało.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Co to XSS i jak React przed nim chroni? Kiedy ta ochrona nie działa? (dangerouslySetInnerHTML)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Ktoś przypina na tablicy karteczkę z instrukcją dla robota. Nieufny portier czyta ją jako zwykły tekst i niczego nie wykonuje.

Na rozmowę: XSS to wstrzyknięcie skryptu, który wykona się na naszej stronie z uprawnieniami użytkownika (kradzież tokenu, akcje w jego imieniu). React escapuje wartości w {} w JSX, więc tekst od użytkownika nie staje się HTML-em. Ochrona nie działa przy dangerouslySetInnerHTML i innerHTML, przy linkach href="javascript:..." z danych użytkownika, przy ref.current.innerHTML, w bibliotekach renderujących markdown/HTML bez sanitizacji i w ręcznie składanym HTML przy SSR. Obrona: unikać surowego HTML, a gdy trzeba, DOMPurify; walidacja protokołu URL; nagłówek Content-Security-Policy (bez inline script, nonce) jako druga linia obrony.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Gdzie trzymać token: localStorage czy cookie httpOnly? Jakie są konsekwencje?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: localStorage to klucz pod wycieraczką: każdy skrypt go znajdzie. Ciasteczko httpOnly to sejf, który otwiera tylko listonosz.

Na rozmowę: localStorage jest prosty i działa z każdym API (nagłówek Authorization), ale każdy skrypt na stronie, także po XSS, może go odczytać i wynieść. Cookie z flagami HttpOnly, Secure, SameSite=Lax/Strict jest niewidoczne dla JS, więc XSS nie wykradnie tokenu, choć dalej może wykonywać żądania w imieniu użytkownika. Cookie wymaga za to ochrony przed CSRF i konfiguracji CORS z credentials. Częsty kompromis: krótki access token w pamięci aplikacji, refresh token w cookie httpOnly, rotacja refresh tokenów.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Co to CSRF i jak chronią przed nim ciasteczka SameSite?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Obca strona namawia Twoją przeglądarkę, żeby wysłała list w Twoim imieniu. SameSite to zasada: list z Twoją pieczątką wysyłamy tylko z Twojego domu.

Na rozmowę: CSRF wykorzystuje to, że przeglądarka sama dołącza ciasteczka do żądań na daną domenę, także wysłanych z cudzej strony (formularz, obrazek, fetch). SameSite=Lax (domyślne w nowych przeglądarkach) nie wysyła ciasteczka przy żądaniach z innej strony poza nawigacją GET najwyższego poziomu, Strict nie wysyła nigdy. Do tego token CSRF (synchronizer albo double-submit), sprawdzanie nagłówków Origin/Referer, brak efektów ubocznych w GET. Przy tokenie w nagłówku Authorization CSRF praktycznie nie występuje.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak działa logowanie przez OAuth2 / OIDC z PKCE w aplikacji SPA?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Nie dajesz aplikacji swojego hasła. Idziesz do zaufanej portierni, która wydaje przepustkę. Żeby nikt jej po drodze nie podmienił, zostawiasz u siebie sekretny znak i pokazujesz go przy odbiorze.

Na rozmowę: Authorization Code Flow z PKCE: aplikacja generuje losowy code_verifier i jego hash code_challenge, przekierowuje do dostawcy (Auth0, Keycloak, Cognito) z challenge, state i scope openid. Po zalogowaniu wraca z jednorazowym code, który aplikacja wymienia na tokeny, dołączając code_verifier, więc przechwycony code jest bezużyteczny. OIDC dodaje id_token z danymi użytkownika. Implicit flow jest przestarzały. Coraz częściej stosuje się wzorzec BFF: tokeny trzyma backend, a przeglądarka dostaje tylko cookie httpOnly.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Co to Content-Security-Policy i jak pomaga frontendowi?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: To lista gości, którzy mogą wejść do domu. Nawet jeśli złodziej przemyci karteczkę, portier nie wpuści jej autora, bo nie ma go na liście.

Na rozmowę: Nagłówek CSP mówi przeglądarce, skąd wolno ładować skrypty, style, obrazy i dokąd wysyłać żądania (script-src, connect-src, img-src). Blokuje inline scripty i eval, chyba że mają nonce lub hash, więc nawet wstrzyknięty HTML nie wykona kodu. Wdrażam najpierw w trybie Content-Security-Policy-Report-Only z raportowaniem, potem egzekwuję. Do tego frame-ancestors przeciw clickjackingowi. To druga linia obrony, nie zamiennik escapowania.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

HTML z CMS-a i redaktorzy z dużymi uprawnieniami

Treści stron i opisy produktów przychodzą z headless CMS jako HTML. Redaktorzy wklejają tam osadzenia z YouTube, tabele i czasem kod z zewnętrznych stron. Pentest pokazał, że konto redaktora może wstawić skrypt, który wykona się u każdego klienta, także w panelu administracyjnym.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy wiesz, że zaufany CMS nie oznacza bezpiecznej treści
Czy znasz sanitizację po stronie serwera i klienta oraz Trusted Types
Czy proponujesz zmianę modelu treści, a nie tylko filtr

Odpowiedź seniora

Konto redaktora może zostać przejęte, więc treść z CMS traktuję jak dane od użytkownika. Najlepszym rozwiązaniem jest zmiana modelu: zamiast surowego HTML CMS zwraca ustrukturyzowane treści (rich text jako JSON, np. Portable Text albo bloki), które renderujemy własnymi komponentami. Osadzenia to osobny typ bloku z białą listą dostawców i parsowaniem tylko identyfikatora filmu.

Tam, gdzie HTML musi zostać, sanitizuję go po stronie serwera przy zapisie lub w BFF (DOMPurify z jsdom albo sanitize-html z białą listą tagów i atrybutów) i drugi raz przy renderowaniu. Usuwam atrybuty zdarzeń, javascript: w linkach, iframe spoza listy.

Obrona w głąb: Content Security Policy z nonce i bez unsafe-inline, Trusted Types (require-trusted-types-for 'script'), które zmuszają cały kod do przejścia przez politykę sanitizacji przed wstawieniem do innerHTML. Panel administracyjny na osobnej domenie, żeby XSS w treści nie dał dostępu do sesji admina.

Typowe wpadki

Założenie, że redaktorzy są zaufani, więc sanitizacja zbędna
Własne wyrażenia regularne do usuwania tagów script
Sanitizacja tylko w jednym miejscu

Dopytają o

Jak wdrożysz Trusted Types w aplikacji z bibliotekami, które używają innerHTML?
Co zrobisz z istniejącymi treściami w bazie?
Jak przetestujesz, że sanitizacja działa po aktualizacji biblioteki?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Refresh tokeny i wiele otwartych kart

SPA używa krótkich access tokenów i rotowanych refresh tokenów. Użytkownicy z kilkoma kartami są losowo wylogowywani. Logi pokazują, że dwie karty jednocześnie odświeżają token, a serwer wykrywa ponowne użycie starego refresh tokenu i unieważnia całą sesję jako kradzież.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy rozumiesz rotację i wykrywanie ponownego użycia tokenu
Czy umiesz skoordynować odświeżanie między kartami
Czy proponujesz zmianę architektury, np. BFF

Odpowiedź seniora

To klasyczny wyścig. Doraźnie koordynuję odświeżanie: w obrębie karty jedna obietnica odświeżania współdzielona przez wszystkie żądania, które dostały 401. Między kartami Web Locks API (navigator.locks.request('refresh')), więc odświeża tylko jedna karta, a pozostałe po zwolnieniu blokady czytają nowy token. Wynik rozsyłam przez BroadcastChannel. Serwer może też mieć krótkie okno łaski, w którym poprzedni refresh token zwraca ten sam nowy token.

Docelowo proponuję wzorzec Backend for Frontend: tokeny OAuth trzyma serwer, a przeglądarka ma tylko cookie sesyjne HttpOnly, Secure, SameSite=Lax. Odświeżanie dzieje się po stronie BFF raz na sesję, więc wyścig znika, a tokeny nie są dostępne dla JavaScriptu przy XSS. Ochronę przed CSRF zapewnia SameSite i nagłówek wymagany przy mutacjach.

Dodaję metryki wylogowań i błędów odświeżania oraz test E2E z dwoma kontekstami przeglądarki, które jednocześnie wygasają.

Typowe wpadki

Wyłączenie rotacji refresh tokenów, żeby problem zniknął
Trzymanie refresh tokenu w localStorage
Brak koordynacji równoległych żądań w jednej karcie

Dopytają o

Jak wylogujesz użytkownika we wszystkich kartach naraz?
Jakie są wady BFF przy wielu klientach mobilnych?
Jak przetestujesz ten wyścig automatycznie?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Podatna albo złośliwa paczka w zależnościach

W piątek po południu pojawia się informacja, że popularna paczka npm, którą macie jako zależność przechodnią, została przejęta i jej nowa wersja wysyła zmienne środowiskowe na zewnętrzny serwer. Nie wiadomo, czy wasze buildy ją pobrały.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy działasz według planu reagowania na incydent
Czy wiesz, gdzie sprawdzić faktycznie zainstalowane wersje
Czy myślisz o rotacji sekretów i zapobieganiu na przyszłość

Odpowiedź seniora

Najpierw ustalam zasięg: sprawdzam lockfile we wszystkich repozytoriach (npm ls, pnpm why) i logi CI, które wersje faktycznie zainstalowano i kiedy. Jeśli lockfile ma przypiętą starszą wersję i CI używa npm ci, ryzyko jest niskie. Blokuję złośliwą wersję przez overrides lub resolutions i wstrzymuję deploye do wyjaśnienia.

Jeśli wersja została pobrana, traktuję sekrety ze środowisk CI i maszyn developerskich jako ujawnione: rotuję tokeny npm, klucze chmury, sekrety w CI, informuję security i sprawdzam logi dostępu. Komunikuję stan zespołom w jednym kanale.

Na przyszłość: zawsze lockfile i npm ci, ignore-scripts domyślnie z wyjątkami, Renovate lub Dependabot z opóźnieniem dla nowych wersji (minimum kilka dni), skanowanie (npm audit, Socket, Snyk) w CI, minimalne uprawnienia tokenów w CI, sekrety tylko w krokach, które ich potrzebują. Po incydencie postmortem bez szukania winnych.

Typowe wpadki

Uruchomienie npm update, żeby szybko „naprawić”
Pominięcie rotacji sekretów, bo „chyba nie pobraliśmy”
Brak lockfile albo npm install w CI

Dopytają o

Jak ograniczysz, co skrypty postinstall mogą zrobić w CI?
Kto w firmie powinien decydować o wstrzymaniu deployów?
Jak ocenisz ryzyko nowej zależności przed jej dodaniem?

Zapytaj Claude Rozwiń case Zagraj interviewera