Spring Security obrona i atak

Większość poradników o Spring Security zaczyna od konfiguracji: „dodaj tę adnotację, wpisz tę linijkę”. Tu robimy odwrotnie. Każdy rozdział zaczyna się od atakującego: czego chce, jakie żądania wysyła i co zobaczy, jeśli danej ochrony nie ma. Dopiero potem pokazujemy, który filtr, nagłówek albo token go zatrzymuje i dlaczego.

Każdy mechanizm ma interaktywny diagram. Zwykle znajdziesz w nim przełącznik 🛡️ ochrona ON/OFF i przycisk 🏴‍☠️ Atakuj. Najpierw wyłącz ochronę i zobacz, jak atak przechodzi. Potem ją włącz i zobacz, w którym miejscu się zatrzymuje. Przyciski „💥” celowo psują konfigurację tak, jak psują ją prawdziwe zespoły.

Kompendium ma trzy poziomy. Rozdziały i bloki mają znaczek — L1 podstawy, L2 praktyk, L3 ekspert. Głębokość wybierasz przełącznikiem w lewym dolnym rogu; głębszy materiał chowa się, dopóki go nie zechcesz. Mapa poniżej skacze do dowolnego rozdziału i odhacza przeczytane.

Fakty sprawdzone w październiku 2026 względem dokumentacji Spring Security 7.1 (aktualna wersja stabilna to 7.1.1), dokumentacji Spring Boot, OWASP Cheat Sheet Series oraz RFC 8725, RFC 9700 i RFC 7636. Przykłady konfiguracji używają składni Spring Security 7: lambda DSL, authorizeHttpRequests, PathPatternRequestMatcher.

Spring Boot ma prostą regułę: jeśli Spring Security jest na classpath, aplikacja webowa jest zabezpieczona domyślnie. Nie musisz pisać ani jednej linijki konfiguracji, żeby dostać całkiem sporo ochron.

Wyobraź sobie najpierw aplikację bez tej zależności. To zwykły serwer, który odpowiada każdemu na wszystko. Atakujący nie musi niczego łamać. Wysyła GET /api/orders i dostaje listę zamówień. Wkleja twoją stronę w niewidzialny <iframe> na swojej witrynie i podsuwa ofierze przycisk do kliknięcia. Wysyła formularz z evil.example, a przeglądarka ofiary dokleja do niego jej ciasteczko sesji.

Dokumentacja Spring Security wymienia, co dostajesz domyślnie w połączeniu ze Spring Boot. W skrócie:

Do tego FilterChainProxy zawsze stosuje HttpFirewall, który odrzuca podejrzane URL-e, i zawsze czyści SecurityContext po żądaniu. Obie rzeczy działają niezależnie od twojej konfiguracji.

Spójrz na dwie ostatnie sondy. Starter nie wie, że zamówienie nr 43 należy do kogoś innego. Nie wie też, że /admin powinien być tylko dla administratorów. Domyślna reguła brzmi „każdy zalogowany może wszystko”. Uprawnienia do konkretnych danych i ról musisz opisać sam. Tym zajmuje się Część III.

@Configuration
@EnableWebSecurity
class SecurityConfig {
  @Bean
  SecurityFilterChain app(HttpSecurity http) throws Exception {
    http
      .authorizeHttpRequests((auth) -> auth
        .requestMatchers("/admin/**").hasRole("ADMIN")
        .anyRequest().authenticated())
      .formLogin(Customizer.withDefaults());
    return http.build();
  }
}

Gdy dodasz własny bean SecurityFilterChain, Spring Boot wycofuje swoją domyślną konfigurację webową (także dla Actuatora). Domyślny UserDetailsService z jednym użytkownikiem zostaje, dopóki nie dodasz własnego UserDetailsService, AuthenticationProvider albo AuthenticationManager.

Spring Security w aplikacjach servletowych to filtry. Każde żądanie HTTP, zanim dotrze do twojego kontrolera, przechodzi przez ciąg filtrów. Każdy filtr może przepuścić żądanie dalej albo je zatrzymać i od razu odpowiedzieć. Kolejność jest kluczowa: filtr wpływa tylko na filtry za nim i na servlet.

Kontener servletów (np. Tomcat) nie zna beanów Springa. Dlatego Spring rejestruje w kontenerze jeden filtr-most, DelegatingFilterProxy. Ten przekazuje pracę do beana FilterChainProxy. FilterChainProxy trzyma listę obiektów SecurityFilterChain i dla każdego żądania wybiera jeden łańcuch: pierwszy, którego matcher pasuje.

Kolejność filtrów w jednym łańcuchu ustala Spring. Najpierw działa CsrfFilter, potem filtry uwierzytelniania (np. BasicAuthenticationFilter, UsernamePasswordAuthenticationFilter), a na końcu AuthorizationFilter, który decyduje o dostępie. Kolejność łańcuchów ustalasz ty, przez @Order. Łańcuch bez @Order jest sprawdzany na końcu.

@Bean @Order(1)
SecurityFilterChain adminApi(HttpSecurity http) throws Exception {
  http.securityMatcher("/api/admin/**")            // najwęższy łańcuch pierwszy
      .authorizeHttpRequests((a) -> a.anyRequest().hasRole("ADMIN"))
      .httpBasic(Customizer.withDefaults());
  return http.build();
}

@Bean @Order(2)
SecurityFilterChain api(HttpSecurity http) throws Exception {
  http.securityMatcher("/api/**")
      .authorizeHttpRequests((a) -> a.anyRequest().authenticated())
      .httpBasic(Customizer.withDefaults());
  return http.build();
}

@Bean   // bez @Order i bez securityMatcher: łapie wszystko inne
SecurityFilterChain web(HttpSecurity http) throws Exception {
  http.authorizeHttpRequests((a) -> a.anyRequest().authenticated())
      .formLogin(Customizer.withDefaults());
  return http.build();
}

Po udanym logowaniu Spring musi gdzieś zapamiętać, kim jesteś. Tym miejscem jest SecurityContextHolder. W środku leży SecurityContext, a w nim obiekt Authentication, który ma trzy ważne pola:

Domyślnie SecurityContextHolder trzyma kontekst w ThreadLocal. Dzięki temu każda metoda w tym samym wątku widzi zalogowanego użytkownika bez przekazywania go w parametrach. FilterChainProxy czyści kontekst po każdym żądaniu, więc wątek z puli nie „pamięta” poprzedniego klienta.

Między żądaniami kontekst żyje w SecurityContextRepository. Domyślnie jest to DelegatingSecurityContextRepository, który zapisuje do sesji HTTP (HttpSessionSecurityContextRepository) i do atrybutu żądania (RequestAttributeSecurityContextRepository). Na początku każdego żądania SecurityContextHolderFilter wczytuje kontekst z repozytorium.

Drugi przełącznik pokazuje pułapkę z nowszych wersji Spring Security. SecurityContextHolderFilter tylko wczytuje kontekst; nie zapisuje go sam, jak robił to dawny SecurityContextPersistenceFilter. Jeśli piszesz własny endpoint logowania, musisz jawnie zapisać kontekst:

SecurityContext context = SecurityContextHolder.createEmptyContext();   // nowy, nie współdzielony
context.setAuthentication(authentication);
SecurityContextHolder.setContext(context);
securityContextRepository.saveContext(context, request, response);       // bez tego: następne żądanie = anonim

Gdy AuthorizationFilter albo method security odmawia dostępu, rzuca wyjątek. Nie piszą odpowiedzi HTTP same. Odpowiedź tworzy ExceptionTranslationFilter, który stoi w łańcuchu przed AuthorizationFilter i łapie dwa typy wyjątków:

• AuthenticationException albo odmowa dla niezalogowanego (także anonimowego) użytkownika → „zacznij uwierzytelnianie”: wyczyść SecurityContextHolder, zapisz żądanie w RequestCache, wywołaj AuthenticationEntryPoint. Ten przekierowuje na stronę logowania albo wysyła 401 z nagłówkiem WWW-Authenticate.
• AccessDeniedException dla w pełni zalogowanego użytkownika (nie anonima ani zalogowanego przez remember-me) → „odmowa”: AccessDeniedHandler, zwykle 403 Forbidden.

Rozróżnienie anonima i użytkownika z remember-me od w pełni zalogowanego robi AuthenticationTrustResolver. Bez niego anonim byłby traktowany jak zalogowany i dostawałby 403 zamiast szansy na logowanie.

http
  .exceptionHandling((ex) -> ex
    .authenticationEntryPoint(new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED))  // API: 401 zamiast 302
    .accessDeniedHandler((req, res, e) -> res.sendError(HttpServletResponse.SC_FORBIDDEN)));

Zagrożenie. Atakujący nie musi włamywać się przez formularz logowania. Wystarczy mu kopia tabeli users: z backupu na otwartym buckecie, z SQL injection w zapomnianym raporcie albo od nieuczciwego pracownika. Jeśli z tej kopii da się odczytać hasła, przejmuje konta u ciebie i (bo ludzie powtarzają hasła) w banku, poczcie i sklepie twoich użytkowników.

Celem nie jest więc „żeby baza nigdy nie wyciekła”. Celem jest to, żeby po wycieku odzyskanie haseł było za drogie, żeby się opłacało.

Jak działa ochrona. Hasło przechodzi przez funkcję jednokierunkową: z hasła łatwo policzyć hash, z hasha nie da się wrócić do hasła. Do tego dochodzi sól, czyli losowe bajty doklejane osobno dla każdego użytkownika, żeby identyczne hasła dawały różne hashe i żeby tablice tęczowe przestały działać.

Sama sól nie wystarcza, bo zwykły SHA-256 jest za szybki. Dlatego hasła przechowuje się adaptacyjną funkcją jednokierunkową: bcrypt, scrypt, Argon2 albo PBKDF2. Celowo zużywają dużo CPU lub pamięci i mają „work factor”, który podkręcasz razem z rozwojem sprzętu. Dokumentacja Springa radzi dobrać go tak, żeby sprawdzenie jednego hasła trwało u ciebie około sekundy.

Zwróć uwagę, co bcrypt zrobił, a czego nie: 123456 i qwerty padły i tak, bo są na samym początku każdego słownika. Wolny hash kupuje czas dla przeciętnych haseł. Na najsłabsze hasła pomaga dopiero blokada przy ich ustawianiu, czyli sprawdzenie, czy nie ma ich w znanych wyciekach (rozdział o brute force).

Konfiguracja w Spring Security 7

Nie wybierasz jednego algorytmu na zawsze. Spring daje DelegatingPasswordEncoder, który zapisuje hash w formacie {id}zakodowaneHasło. Prefiks mówi, którym enkoderem sprawdzić hasło, a nowe hasła zawsze koduje bieżącym domyślnym (idForEncode), czyli dziś bcrypt:

@Bean
PasswordEncoder passwordEncoder() {
    // {bcrypt} dla nowych haseł, ale potrafi sprawdzić też {noop}, {pbkdf2}, {scrypt}, {argon2}...
    return PasswordEncoderFactories.createDelegatingPasswordEncoder();
}

// zapis w bazie wygląda tak:
// {bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

// ❌ nie rób tego: szybki hash, brak soli, brak work factor
String hash = DigestUtils.sha256Hex(rawPassword);

Prefiks {bcrypt} nie jest tajemnicą, którą trzeba ukrywać. Bezpieczeństwo hasła nie opiera się na tym, że algorytm jest sekretny, a hash bcrypt i tak zdradza się początkiem $2a$.

Zagrożenie. Zanim ktoś zacznie zgadywać hasła, chce wiedzieć, które loginy w ogóle istnieją. Lista prawdziwych kont (user enumeration) zmniejsza pracę o rzędy wielkości, a przy okazji zdradza, że prezes@firma.pl ma u ciebie konto. Wystarczy, że logowanie odpowiada inaczej dla „nie ma takiego użytkownika”, a inaczej dla „złe hasło”.

Jak działa ochrona. Żądanie logowania przechodzi przez łańcuch obiektów, z których każdy ma jedno zadanie. Filtr (UsernamePasswordAuthenticationFilter dla formularza, BasicAuthenticationFilter dla HTTP Basic) wyciąga login i hasło do obiektu UsernamePasswordAuthenticationToken. Przekazuje go do AuthenticationManager, którego typową implementacją jest ProviderManager.

ProviderManager ma listę AuthenticationProvider-ów i pyta je po kolei. Login z hasłem obsługuje DaoAuthenticationProvider: przez UserDetailsService wczytuje użytkownika, a przez PasswordEncoder porównuje hasło. Gdy żaden provider nie obsługuje danego typu tokenu, leci ProviderNotFoundException.

Ochrona przed enumeracją siedzi w samym providerze. Domyślnie hideUserNotFoundExceptions ma wartość true, więc nieznany login i złe hasło kończą się tym samym BadCredentialsException. A gdy użytkownika nie ma, DaoAuthenticationProvider i tak porównuje podane hasło z atrapą hasha, żeby czas odpowiedzi wyglądał podobnie.

Konfiguracja w Spring Security 7

Zwykle nie piszesz żadnego providera. Wystarczy bean UserDetailsService i PasswordEncoder, a Spring Security złoży z nich DaoAuthenticationProvider:

@Bean
SecurityFilterChain security(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated())
        .formLogin(Customizer.withDefaults())   // POST /login, błąd → /login?error
        .httpBasic(Customizer.withDefaults());  // 401 + WWW-Authenticate
    return http.build();
}

@Bean
UserDetailsService users(UserRepository repo) {
    return username -> repo.findByUsername(username)
        .map(u -> User.withUsername(u.login()).password(u.hash()).roles("USER").build())
        .orElseThrow(() -> new UsernameNotFoundException("not found"));
}

// ❌ psuje ochronę: nieznany login daje inny wyjątek niż złe hasło
provider.setHideUserNotFoundExceptions(false);
// ❌ i to samo, ręcznie: handler zwraca klientowi treść wyjątku
response.getWriter().write("{\"error\":\"" + exception.getMessage() + "\"}");

Zagrożenie. Atak „w lewo i w prawo” ma trzy odmiany. Brute force to wiele haseł na jedno konto. Password spraying to jedno popularne hasło na tysiące kont. Credential stuffing to pary login + hasło z wycieku innego serwisu, sprawdzane u ciebie. Ten ostatni jest najgroźniejszy, bo każda para jest „prawdziwa” i trafia tam, gdzie ktoś powtórzył hasło.

I uwaga, która zaskakuje: Spring Security nie ma wbudowanego limitu prób logowania ani blokady konta po N błędach. Daje klocki (zdarzenia logowania, flagę accountNonLocked, sprawdzanie wycieków, MFA), ale politykę limitów składasz sam albo stawiasz ją przed aplikacją.

Jak działa ochrona. Żadna pojedyncza warstwa nie wystarcza. Limit prób (na bramce API albo we własnym kodzie, liczony per konto, a nie tylko per IP) spowalnia bota, ale botnet rozkłada próby. CompromisedPasswordChecker odrzuca hasło, które jest w znanych wyciekach, nawet jeśli pasuje. MFA sprawia, że samo hasło przestaje wystarczać.

Zauważ kolejność w kodzie Springa: CompromisedPasswordChecker działa dopiero po poprawnym porównaniu hasła, tuż przed utworzeniem udanego Authentication. Zamiast sesji leci CompromisedPasswordException, a ty decydujesz w AuthenticationFailureHandler, co dalej, na przykład przekierowujesz na /reset-password.

Konfiguracja w Spring Security 7

@Bean
CompromisedPasswordChecker compromisedPasswordChecker() {
    return new HaveIBeenPwnedRestApiPasswordChecker();   // DaoAuthenticationProvider podchwyci bean sam
}

@Bean
SecurityFilterChain security(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated())
        .formLogin(login -> login.failureHandler((req, res, ex) -> {
            if (ex instanceof CompromisedPasswordException) {
                res.sendRedirect("/reset-password");
            } else {
                res.sendRedirect("/login?error");
            }
        }));
    return http.build();
}

// Klocek do własnego limitu: zdarzenia logowania
@Component
class LoginAttempts {
    @EventListener
    void onFailure(AuthenticationFailureBadCredentialsEvent e) { /* licznik per konto, np. w Redisie */ }
    @EventListener
    void onSuccess(AuthenticationSuccessEvent e) { /* wyzeruj licznik */ }
}

Zagrożenie. Po zalogowaniu przeglądarka nie wysyła już hasła. Wysyła identyfikator sesji, najczęściej w ciasteczku JSESSIONID. Kto zna ten identyfikator, jest tobą. Atakujący może go ukraść (przez skrypt XSS, niezaszyfrowane połączenie) albo, sprytniej, podrzucić ci swój identyfikator przed logowaniem. Ten drugi atak to session fixation.

Jak działa ochrona. Spring Security przy logowaniu automatycznie zmienia identyfikator sesji. Domyślna strategia changeSessionId zostawia tę samą sesję z danymi, ale nadaje jej nowe ID przez HttpServletRequest#changeSessionId(). Stary identyfikator, który zna atakujący, po prostu przestaje istnieć.

Przed kradzieżą chronią flagi ciasteczka: HttpOnly (skrypt na stronie nie przeczyta go z document.cookie), Secure (tylko po HTTPS) i SameSite (ogranicza wysyłanie z innych stron).

Konfiguracja w Spring Security 7

@Bean
SecurityFilterChain security(HttpSecurity http) throws Exception {
    http
        .sessionManagement(session -> session
            .sessionFixation(fix -> fix.changeSessionId())  // domyślne, piszesz tylko dla czytelności
            .maximumSessions(1)                              // jedna aktywna sesja na użytkownika
        )
        .logout(logout -> logout
            .addLogoutHandler(new HeaderWriterLogoutHandler(
                new ClearSiteDataHeaderWriter(ClearSiteDataHeaderWriter.Directive.COOKIES)))
        );
    return http.build();
}

@Bean   // potrzebny, żeby limit sesji wiedział, które sesje wygasły
HttpSessionEventPublisher httpSessionEventPublisher() {
    return new HttpSessionEventPublisher();
}

# application.properties (Spring Boot)
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.same-site=lax
server.servlet.session.timeout=30m   # domyślnie i tak 30m

// ❌ wyłącza ochronę, zostawiając aplikację podatną
.sessionManagement(session -> session.sessionFixation(fix -> fix.none()))

Wylogowanie robi więcej, niż widać. POST /logout unieważnia sesję HTTP, czyści SecurityContext, sprząta remember-me i zapisany token CSRF, a potem przekierowuje na /login?logout. GET /logout pokazuje tylko stronę z potwierdzeniem, bo wylogowanie wymaga tokenu CSRF. Inaczej obca strona mogłaby cię wylogować jednym obrazkiem. Nagłówek Clear-Site-Data dodatkowo każe przeglądarce wyczyścić ciasteczka, storage i cache tej strony.

Zagrożenie. Checkbox „zapamiętaj mnie” zostawia w przeglądarce długowieczne ciasteczko remember-me, domyślnie ważne dwa tygodnie. Kiedy sesja wygaśnie, aplikacja zaloguje cię z niego bez hasła. Dla atakującego to łup lepszy niż JSESSIONID: żyje dłużej i przetrwa zamknięcie przeglądarki.

Jak działa ochrona. Spring ma dwie implementacje. TokenBasedRememberMeServices trzyma wszystko w ciasteczku: base64(username:expirationTime:algorithmName:podpis), gdzie podpis to hash z loginu, czasu wygaśnięcia, hasła i tajnego klucza (domyślnie SHA-256). Działa bez bazy, ale skradzione ciasteczko jest ważne z każdej przeglądarki do końca ważności. Unieważnisz je tylko zmianą hasła (lub klucza).

PersistentTokenBasedRememberMeServices trzyma w ciasteczku parę series + token, a w tabeli persistent_logins ich kopię. Przy każdym użyciu seria zostaje, a token jest losowany na nowo. Gdy przyjdzie znana seria ze starym tokenem, ktoś użył kopii ciasteczka. Spring usuwa wtedy wszystkie tokeny tego użytkownika i rzuca CookieTheftException.

Konfiguracja w Spring Security 7

@Bean
PersistentTokenRepository rememberMeTokens(DataSource dataSource) {
    var repo = new JdbcTokenRepositoryImpl();   // tabela persistent_logins(username, series, token, last_used)
    repo.setDataSource(dataSource);
    return repo;
}

@Bean
SecurityFilterChain security(HttpSecurity http, PersistentTokenRepository tokens) throws Exception {
    http
        .formLogin(Customizer.withDefaults())
        .rememberMe(remember -> remember
            .tokenRepository(tokens)          // bez tego: TokenBasedRememberMeServices
            .tokenValiditySeconds(7 * 24 * 3600)
            .useSecureCookie(true)
        );
    return http.build();
}

Zagrożenie. Hasło można wyłudzić, a fałszywa strona logowania wygląda dziś tak samo jak prawdziwa. Drugi składnik (kod z e-maila, SMS-a, aplikacji) bardzo utrudnia atak, ale kod wpisywany ręcznie ma słaby punkt: człowiek nie sprawdza adresu strony. Phishing w czasie rzeczywistym przekazuje dalej i hasło, i kod.

Jak działa ochrona. Spring Security 7 wprowadził MFA jako zwykłe uprawnienia. Każdy mechanizm logowania dokłada do Authentication FactorGrantedAuthority: hasło daje FACTOR_PASSWORD, jednorazowy token FACTOR_OTT, a passkey FACTOR_WEBAUTHN. Adnotacja @EnableMultiFactorAuthentication sprawia, że reguły autoryzacji wymagają kompletu składników. Brakuje któregoś? Spring sam przekierowuje do odpowiedniego ekranu logowania.

One-Time Token (OTT) to jednorazowy token generowany po stronie serwera i dostarczany na przykład jako magic link e-mailem. Domyślnie wygasa po 5 minutach. Uwaga: to nie jest TOTP z aplikacji, bo nie wymaga wcześniejszego parowania. Passkey (WebAuthn) to para kluczy: prywatny zostaje w urządzeniu, serwer zna publiczny. Kluczowe jest to, że przeglądarka wiąże passkey z domeną (rpId), a serwer sprawdza, z jakiego origin przyszło podpisane wyzwanie. Na fałszywej domenie passkey po prostu nie zadziała.

Konfiguracja w Spring Security 7

@Configuration
@EnableWebSecurity
@EnableMultiFactorAuthentication(authorities = {
    FactorGrantedAuthority.PASSWORD_AUTHORITY,
    FactorGrantedAuthority.OTT_AUTHORITY })
class SecurityConfig {

    @Bean
    SecurityFilterChain security(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/admin/**").hasRole("ADMIN")  // + FACTOR_PASSWORD + FACTOR_OTT
                .anyRequest().authenticated()                    // + FACTOR_PASSWORD + FACTOR_OTT
            )
            .formLogin(Customizer.withDefaults())
            .oneTimeTokenLogin(Customizer.withDefaults());       // wysyłkę tokenu dopisujesz sam
        return http.build();
    }
}

Passkeys włączasz zależnością spring-security-webauthn i jednym blokiem DSL:

http.webAuthn(webAuthn -> webAuthn
    .rpId("bank.example")                       // domena, do której przypięte są passkeys
    .allowedOrigins("https://bank.example"));   // skąd wolno przyjąć podpis

Rejestracja nowego klucza odbywa się pod /webauthn/register, a domyślna strona logowania dostaje przycisk logowania passkeyem. OneTimeTokenGenerationSuccessHandler (wysyłkę maila lub SMS-a) musisz napisać sam, bo Spring nie wie, jak dotrzeć do twoich użytkowników.

var mfa = AuthorizationManagerFactories.multiFactor()
    .requireFactors(FactorGrantedAuthority.PASSWORD_AUTHORITY, FactorGrantedAuthority.OTT_AUTHORITY)
    .build();

var passwordIn30m = AuthorizationManagerFactories.multiFactor()
    .requireFactor(factor -> factor.passwordAuthority().validDuration(Duration.ofMinutes(30)))
    .build();

http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/admin/**").access(passwordIn30m.hasRole("ADMIN"))
    .requestMatchers("/user/settings/**").access(mfa.authenticated())
    .anyRequest().authenticated());

Zagrożenie. Masz panel /admin/users z listą klientów. Atakujący nie musi łamać hasła admina. Wystarczy mu zwykłe konto i reguła ustawiona w złym miejscu listy. Wtedy sam framework otworzy mu drzwi.

Drugi scenariusz: ktoś dodaje nowy endpoint /internal/metrics i zapomina dopisać dla niego regułę. Jeśli twoja konfiguracja „przepuszcza wszystko, czego nie wymieniono”, ten endpoint jest publiczny od pierwszego deploya.

Jak działa ochrona

W authorizeHttpRequests deklarujesz pary: dopasowanie → reguła. AuthorizationFilter przechodzi je w kolejności zapisu i stosuje tylko pierwszą pasującą. Kolejne reguły już się nie liczą, nawet jeśli są bardziej szczegółowe.

Stąd zasada: najpierw wąskie ścieżki (/admin/**), potem szersze, a na samym końcu anyRequest(). Na końcu najlepiej postawić anyRequest().denyAll(). Wtedy lista działa jak allow list: wszystko, czego nie wymieniłeś, jest zabronione.

Konfiguracja w Spring Security 7

// ❌ szeroka reguła na górze połyka wszystko pod spodem
http.authorizeHttpRequests((authorize) -> authorize
    .requestMatchers("/**").authenticated()
    .requestMatchers("/admin/**").hasRole("ADMIN")   // nigdy nie zostanie sprawdzona
    .anyRequest().permitAll()
);

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests((authorize) -> authorize
        .dispatcherTypeMatchers(DispatcherType.FORWARD, DispatcherType.ERROR).permitAll()
        .requestMatchers("/public/**", "/login").permitAll()
        .requestMatchers("/admin/**").hasRole("ADMIN")
        .requestMatchers(HttpMethod.GET, "/orders/**").hasAuthority("orders:read")
        .requestMatchers(HttpMethod.POST, "/orders/**").hasAuthority("orders:write")
        .anyRequest().denyAll()                  // allow list: reszta zabroniona
    );
    return http.build();
}

Zagrożenie. Reguła /admin/** chroni ścieżkę w tej postaci, w jakiej zobaczy ją matcher. Kontener servletów może jednak zrozumieć ten sam adres inaczej. Jeśli matcher widzi /admin;x=1/users i nic nie dopasowuje, a kontener po obcięciu parametru wywołuje kontroler /admin/users, atakujący omija regułę bez łamania czegokolwiek.

Dokumentacja Spring Security wprost wymienia te sztuczki: parametry ścieżki po średniku, sekwencje /../ i podwójne ukośniki //. Specyfikacja servletów nie określa dokładnie, co trafia do servletPath i pathInfo, a kontenery zachowują się tu różnie.

Jak działa ochrona

FilterChainProxy przepuszcza każde żądanie przez HttpFirewall, zanim zadziała jakikolwiek filtr. Domyślną implementacją jest StrictHttpFirewall, który odrzuca podejrzane żądania, zamiast próbować je naprawiać. Domyślnie odrzuca:

• URL-e nieznormalizowane, np. z /../ lub /./, i z podwójnym ukośnikiem //;
• średnik ;, zakodowany ukośnik %2F, backslash \ i %5C, zakodowany procent %25, znak NUL;
• znaki spoza drukowalnego ASCII w URI, w tym CR i LF;
• metody HTTP spoza listy DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, więc np. TRACE;
• niedozwolone nazwy i wartości nagłówków oraz nazwy parametrów (znaki kontrolne, niezdefiniowane code pointy).

Odrzucenie to wyjątek RequestRejectedException. FilterChainProxy obsługuje go domyślnie przez HttpStatusRequestRejectedHandler, który zwraca 400 Bad Request.

Konfiguracja w Spring Security 7

Nic nie musisz włączać, bo StrictHttpFirewall działa domyślnie. Konfigurujesz go tylko wtedy, gdy chcesz coś poluzować, i robisz to możliwie wąsko:

@Bean
StrictHttpFirewall httpFirewall() {
    StrictHttpFirewall firewall = new StrictHttpFirewall();
    firewall.setAllowedHttpMethods(List.of("GET", "POST"));   // zawęża listę metod
    // firewall.setAllowSemicolon(true);  // tylko jeśli naprawdę używasz matrix variables
    return firewall;
}

Zagrożenie. Reguły URL widzą tylko żądanie HTTP: adres, metodę i typ dispatchu. Ten sam serwis bywa jednak wołany z kontrolera REST, z kolejki, z joba i z GraphQL. Dlatego zabezpieczasz go w warstwie serwisów adnotacjami. Problem w tym, że adnotacja działa przez proxy Springa, a wywołanie this.metoda() wewnątrz klasy omija proxy.

Jak działa ochrona

@EnableMethodSecurity włącza domyślnie @PreAuthorize, @PostAuthorize, @PreFilter i @PostFilter. Spring Boot nie włącza method security sam z siebie, więc tę adnotację musisz dodać.

Gdy wołasz metodę beana, trafiasz najpierw do proxy. W łańcuchu proxy siedzi AuthorizationManagerBeforeMethodInterceptor. Wywołuje on PreAuthorizeAuthorizationManager#authorize, który liczy wyrażenie SpEL. Przy odmowie publikowany jest AuthorizationDeniedEvent, leci AccessDeniedException, a w żądaniu HTTP ExceptionTranslationFilter zamienia go na 403.

Dokumentacja Spring Framework mówi wprost: wywołanie na samym sobie przez jawne lub niejawne this omija advice. Proxy nie ma szansy zadziałać.

Konfiguracja w Spring Security 7

@Service
public class OrderService {
    public void archiveAll() {                    // ❌ brak kontroli na granicy beana
        for (Long id : staleIds()) this.deleteOrder(id);   // this. → obok proxy
    }
    @PreAuthorize("hasRole('ADMIN')")
    public void deleteOrder(Long id) { … }
}

@Configuration
@EnableMethodSecurity
class MethodSecurityConfig { }

@Service
@PreAuthorize("hasRole('ADMIN')")                // klasa: każda publiczna metoda dziedziczy regułę
public class OrderAdminService {
    public void archiveAll() { … }
    public void deleteOrder(Long id) { … }
}

@Service
class OrderQueries {
    @PostAuthorize("returnObject.owner == authentication.name")
    public Order read(Long id) { … }

    @PostFilter("filterObject.owner == authentication.name")
    public List<Order> recent() { … }
}

Zagrożenie. Zalogowany jan ogląda swoje zamówienie pod /api/orders/42. Liczba w URL-u to bezpośrednia referencja do obiektu, często klucz główny z bazy. Jeśli serwer nie sprawdza, czy zamówienie należy do jan, to /api/orders/43 pokaże cudzy adres, telefon i zawartość koszyka.

OWASP nazywa to IDOR (Insecure Direct Object Reference). W API ten sam błąd nazywa się BOLA. Składają się na niego trzy rzeczy: obiekt, referencja do niego i brak sprawdzenia uprawnień na poziomie obiektu. Spring Security tego za ciebie nie zrobi, bo nie wie, kto jest właścicielem zamówienia.

Jak działa ochrona

Sprawdzasz własność przy każdym dostępie do obiektu. Najprostszy wariant, polecany przez OWASP, to zapytanie zawężone do zbioru, do którego użytkownik ma dostęp: findByIdAndOwner(id, aktualnyUser). Cudzy rekord po prostu nie istnieje dla tego zapytania, więc dostajesz 404.

Inne warianty w Springu: @PostAuthorize("returnObject.owner == authentication.name") po odczycie, metoda beana w SpEL (@PreAuthorize("@orderAuthz.canRead(#id, authentication)")) albo własny AuthorizationManager. Najważniejsze, żeby tożsamość brać z kontekstu bezpieczeństwa, a nie z parametru żądania.

Konfiguracja w Spring Security 7

@GetMapping("/api/orders/{id}")
Order get(@PathVariable Long id) {
    return orders.findById(id).orElseThrow();      // ❌ każdy zalogowany czyta każde zamówienie
}

@GetMapping("/api/orders/{id}")
Order get(@PathVariable Long id, Authentication auth) {
    return orders.findByIdAndOwner(id, auth.getName())   // zawężone do właściciela
        .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
}

// alternatywnie w serwisie:
@PostAuthorize("returnObject.owner == authentication.name")
public Order read(Long id) { return orders.findById(id).orElseThrow(); }

Zagrożenie. Tym razem nie ma sprytnego atakującego. Jest literówka. Odwrócona hierarchia ról (ROLE_USER > ROLE_ADMIN) daje każdemu użytkownikowi uprawnienia admina. Pomylone hasAuthority("ADMIN") zamiast hasRole("ADMIN") zamyka panel przed prawdziwymi adminami, a ktoś w pośpiechu „naprawia” to przez permitAll().

Jak działa ochrona

Uprawnienia użytkownika to kolekcja GrantedAuthority, czyli w praktyce stringów. Rola to authority z prefiksem ROLE_. hasRole("ADMIN") to skrót, który dokleja prefiks i szuka ROLE_ADMIN. hasAuthority("ADMIN") szuka dokładnie ADMIN. Prefiks zmienisz beanem GrantedAuthorityDefaults.

hasRole("ROLE_ADMIN") nie przejdzie: AuthorityAuthorizationManager rzuca wyjątek, że rola nie powinna zaczynać się od ROLE_, bo prefiks jest doklejany automatycznie. W Resource Server scope'y z JWT stają się authorities z prefiksem SCOPE_, więc sprawdzasz je przez hasAuthority("SCOPE_messages").

RoleHierarchy mówi, które role zawierają inne. ROLE_ADMIN > ROLE_STAFF czytasz jako „ADMIN zawiera STAFF”. Użytkownik z ROLE_ADMIN zachowuje się wtedy tak, jakby miał wszystkie role poniżej.

Konfiguracja w Spring Security 7

@Bean
static RoleHierarchy roleHierarchy() {
    return RoleHierarchyImpl.withDefaultRolePrefix()
        .role("ADMIN").implies("STAFF")
        .role("STAFF").implies("USER")
        .build();
    // albo: RoleHierarchyImpl.fromHierarchy("ROLE_ADMIN > ROLE_STAFF\nROLE_STAFF > ROLE_USER")
}

// jeśli używasz @PreAuthorize itp., podaj hierarchię także do handlera wyrażeń
@Bean
static MethodSecurityExpressionHandler methodSecurityExpressionHandler(RoleHierarchy roleHierarchy) {
    DefaultMethodSecurityExpressionHandler handler = new DefaultMethodSecurityExpressionHandler();
    handler.setRoleHierarchy(roleHierarchy);
    return handler;
}

http.authorizeHttpRequests((authorize) -> authorize
    .requestMatchers("/admin/**").hasRole("ADMIN")              // szuka ROLE_ADMIN
    .requestMatchers("/db/**").hasAllAuthorities("db", "ROLE_ADMIN")
    .anyRequest().authenticated()
);

final class SuspendedAccountManager implements AuthorizationManager<RequestAuthorizationContext> {
    @Override
    public AuthorizationResult authorize(Supplier<? extends Authentication> auth, RequestAuthorizationContext ctx) {
        boolean suspended = accounts.isSuspended(auth.get().getName());
        return new AuthorizationDecision(!suspended);
    }
}
// .requestMatchers("/orders/**").access(new SuspendedAccountManager())

Zagrożenie. Jesteś zalogowany w banku (bank.example), sesja siedzi w ciasteczku JSESSIONID. W drugiej karcie otwierasz „śmieszne koty” na evil.example. Ta strona nie zna twojego hasła i nie widzi twojego ciasteczka — ale nie musi. Wystarczy, że każe twojej przeglądarce wysłać żądanie do banku. Przeglądarka sama dołoży ciasteczko sesji.

To jest CSRF (Cross-Site Request Forgery, fałszowanie żądań między witrynami): atakujący nie kradnie sesji, tylko pożycza ją na jedno żądanie, które zmienia stan — przelew, zmiana e-maila, usunięcie konta.

Jak działa ochrona. Sesja w ciasteczku jest automatyczna, więc sama niczego nie dowodzi. Potrzebujesz czegoś, co ma tylko twoja własna strona. Spring Security stosuje wzorzec synchronizer token: serwer wydaje losowy token CSRF, twoja strona wkłada go do każdego formularza (pole _csrf) albo nagłówka, a CsrfFilter porównuje go z tokenem zapamiętanym po stronie serwera. Strona evil.example nie umie tego tokenu odczytać — przeglądarka nie pozwala jej czytać stron banku — więc nie umie go podrobić.

Druga, uzupełniająca warstwa to atrybut ciasteczka SameSite. SameSite=Lax mówi przeglądarce: „nie doklejaj tego ciasteczka do żądań z obcych witryn, chyba że to zwykłe przejście linkiem metodą bezpieczną (GET)”. Strict nie dokleja go do żadnych żądań z obcych witryn — nawet do kliknięcia w link, co bywa niewygodne dla użytkownika.

Zauważ wariant z linkiem GET: token CSRF go nie zatrzymuje, bo Spring Security sprawdza token tylko dla metod „niebezpiecznych” (np. POST). GET, HEAD, OPTIONS i TRACE mają być tylko do odczytu — to twój obowiązek, nie frameworka. Endpoint, który robi przelew na GET, jest dziurawy niezależnie od konfiguracji.

Konfiguracja w Spring Security 7. Dobra wiadomość: ochrona CSRF jest włączona domyślnie dla metod niebezpiecznych. Jeśli renderujesz formularze Thymeleafem albo tagami formularzy Springa, token trafia do <form method="post"> automatycznie.

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated())
        .formLogin(withDefaults());
    // CSRF: nic nie piszesz — jest włączone, token w sesji
    // (HttpSessionCsrfTokenRepository) i maskowany przeciw BREACH
    return http.build();
}

Aplikacja SPA (React, Angular) czyta token z ciasteczka XSRF-TOKEN i odsyła go w nagłówku X-XSRF-TOKEN. Ręczne złożenie tego było kiedyś pułapką; od 7.0 jest jedna linijka:

http.csrf((csrf) -> csrf.spa());

// ❌ „REST API, więc bez CSRF” — a logowanie jest przez ciasteczko sesji
http
    .csrf((csrf) -> csrf.disable())
    .formLogin(withDefaults());

Zagrożenie. Przeglądarka ma wbudowaną zasadę Same-Origin Policy (SOP): skrypt ze strony https://evil.example może wysłać żądanie do https://api.bank.example, ale nie może przeczytać odpowiedzi. „Origin” to trójka schemat + host + port. SOP to twoja domyślna tarcza.

CORS (Cross-Origin Resource Sharing) to sposób, w jaki serwer poluzowuje SOP: nagłówek Access-Control-Allow-Origin mówi przeglądarce „temu originowi wolno czytać moje odpowiedzi”. Atakujący marzy o tym, żebyś poluzował za bardzo — wtedy jego JavaScript przeczyta dane zalogowanej ofiary.

Jak działa ochrona. Decyzję „czy JS może przeczytać odpowiedź” podejmuje przeglądarka na podstawie nagłówków z serwera. Twoim zadaniem jest wysłać te nagłówki tylko zaufanym originom — z jawnej listy. Jedna ważna reguła przeglądarki: jeśli zezwalasz na poświadczenia (Access-Control-Allow-Credentials: true), odpowiedź z Access-Control-Allow-Origin: * zostanie odrzucona. Dlatego leniwi „naprawiają” to odbijaniem originu — i otwierają dziurę.

Drugi mechanizm to preflight: przed „nietypowym” żądaniem (np. PUT z Content-Type: application/json) przeglądarka pyta najpierw OPTIONS, czy wolno. Preflight nie niesie ciasteczek. Jeśli Spring Security sprawdza uwierzytelnienie przed obsługą CORS, uzna preflight za anonimowy i go odrzuci — a przeglądarka nigdy nie wyśle właściwego żądania.

—

Konfiguracja w Spring Security 7. Dostarcz bean CorsConfigurationSource o nazwie corsConfigurationSource (np. UrlBasedCorsConfigurationSource) i włącz http.cors(…) — wtedy CorsFilter obsłuży CORS przed Spring Security, także preflight. Jeśli używasz CORS ze Spring MVC i nie podasz źródła, cors(withDefaults()) weźmie konfigurację MVC.

@Bean
UrlBasedCorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration cfg = new CorsConfiguration();
    cfg.setAllowedOrigins(List.of("https://app.bank.example")); // jawna lista
    cfg.setAllowedMethods(List.of("GET", "POST", "PUT"));
    cfg.setAllowedHeaders(List.of("Content-Type", "X-XSRF-TOKEN"));   // bez tego preflight PUT z JSON odpada
    cfg.setAllowCredentials(true);
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/api/**", cfg);
    return source;
}

@Bean
SecurityFilterChain api(HttpSecurity http) throws Exception {
    http
        .cors(withDefaults())   // użyje beana powyżej
        .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated());
    return http.build();
}

// ❌ „naprawa” CORS, która oddaje dane każdemu
cfg.setAllowedOriginPatterns(List.of("*"));
cfg.setAllowCredentials(true);

Zagrożenie. Dwa klasyki. Clickjacking: atakujący osadza twoją stronę w niewidzialnej ramce (iframe) nad własnym przyciskiem „Odbierz nagrodę”. Ofiara klika nagrodę, a naprawdę klika „Usuń konto” w twojej aplikacji — z własną sesją. XSS (Cross-Site Scripting): atakujący przemyca skrypt do treści, którą twoja strona wyświetla (np. komentarz), i ten skrypt działa z uprawnieniami twojej strony.

Jak działa ochrona. Nagłówki bezpieczeństwa to polecenia dla przeglądarki dołączane do każdej odpowiedzi. Spring Security dodaje domyślnie taki zestaw:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains   ← tylko w odpowiedziach HTTPS
X-Frame-Options: DENY
X-XSS-Protection: 0

X-Frame-Options: DENY zabrania renderowania strony w ramce — clickjacking traci podłoże. Nowocześniejszy odpowiednik to dyrektywa CSP frame-ancestors. X-XSS-Protection: 0 wygląda dziwnie, ale to celowe: wbudowany w przeglądarki filtr XSS jest przestarzały, a OWASP zaleca jawne wyłączenie go. Prawdziwą obroną przed XSS jest kodowanie wyjścia, a w drugiej linii Content-Security-Policy — której Spring nie dodaje sam, bo rozsądna polityka zależy od twojej aplikacji.

Konfiguracja w Spring Security 7. Domyślne nagłówki dostajesz za darmo. Konfigurujesz tylko odstępstwa i dodatki:

http
    .headers((headers) -> headers
        .frameOptions((frame) -> frame.sameOrigin())        // gdy sam osadzasz swoje strony
        .contentSecurityPolicy((csp) -> csp
            .policyDirectives("script-src 'self'; object-src 'none'; frame-ancestors 'self'"))   // spójne z sameOrigin()
        .referrerPolicy((ref) -> ref.policy(ReferrerPolicy.SAME_ORIGIN))
        .permissionsPolicyHeader((perm) -> perm.policy("geolocation=(self)"))
    );

Referrer-Policy i Permissions-Policy też nie są domyślne — Spring daje DSL, ale wartości musisz wybrać sam.

Zagrożenie. Masz HTTPS i przekierowanie z http://. Ale użytkownik wpisuje w kawiarni po prostu bank.example. Pierwsze żądanie idzie otwartym tekstem — a w tej sieci siedzi atakujący (man-in-the-middle). Spring Security nie obsługuje samych połączeń TLS — to robi serwer albo proxy — ale daje narzędzia, które pomagają.

Jak działa ochrona. HSTS (Strict-Transport-Security) mówi przeglądarce: „przez najbliższy rok rozmawiaj ze mną tylko po HTTPS”. Przeglądarka zapamiętuje to i sama zamienia każde http://bank.example na https://, zanim cokolwiek wyśle. Nie da się też kliknąć „kontynuuj mimo to” przy fałszywym certyfikacie. Spring Security dodaje HSTS domyślnie — ale zgodnie z RFC 6797 tylko do odpowiedzi HTTPS.

Haczyk: zanim przeglądarka zobaczy pierwszą odpowiedź HTTPS, nic nie wie. Pierwsza wizyta (albo wizyta po wygaśnięciu max-age) wciąż jest narażona. Dlatego istnieje lista preload wbudowana w przeglądarki — domena z tej listy jest chroniona od pierwszego żądania.

Konfiguracja w Spring Security 7. W 7.x przekierowanie na HTTPS nazywa się redirectToHttps. HSTS jest domyślnie włączone (max-age=31536000 ; includeSubDomains); zmieniasz je tylko, gdy chcesz np. preload:

http
    .redirectToHttps(withDefaults())          // http:// → https://
    .headers((headers) -> headers
        .httpStrictTransportSecurity((hsts) -> hsts
            .includeSubDomains(true)
            .preload(true)                    // zgoda na listę preload (sam wpis zgłaszasz na hstspreload.org)
            .maxAgeInSeconds(31536000)));

Za proxy. W chmurze TLS zwykle kończy się na load balancerze, a do aplikacji idzie zwykłe HTTP na 192.168.0.107:8080. Bez konfiguracji aplikacja myśli, że żądanie przyszło po HTTP z adresu wewnętrznego — więc nagłówek HSTS się nie pojawi, a przekierowania i linki zwrotne (np. redirect-uri w OAuth) mają zły host. Proxy przekazuje oryginał w nagłówkach Forwarded (RFC 7239) albo X-Forwarded-Proto/Host/For; aplikacja musi umieć je zastosować: Tomcat RemoteIpValve, Jetty ForwardedRequestCustomizer albo ForwardedHeaderFilter. W Spring Boot — właściwość server.forward-headers-strategy.

# application.properties (Spring Boot)
server.forward-headers-strategy=native   # albo: framework

Zagrożenie. Twoja aplikacja ma przycisk „Zaloguj przez firmowe SSO”. Użytkownik loguje się u dostawcy tożsamości (IdP), a ten odsyła przeglądarkę z powrotem z jednorazowym kodem autoryzacji w adresie URL. Kod wymienia się na tokeny. Atakujący chce jednego z dwóch: przechwycić ten kod i wymienić go sam (dostaje tokeny ofiary) albo wcisnąć ofierze swój kod, żeby zalogowała się na jego konto i zostawiła tam swoje dane.

Trzy role: klient (twoja aplikacja), serwer autoryzacji (IdP: Keycloak, Entra ID, Okta, Spring Authorization Server) i serwer zasobów (API, które przyjmuje token). OAuth 2.0 mówi, jak klient dostaje access token. OIDC (OpenID Connect) dokłada ID token — informację, kto się zalogował.

Jak działa ochrona. PKCE (RFC 7636): zanim klient wyśle przeglądarkę do IdP, losuje tajny code_verifier i wysyła tylko jego skrót (code_challenge). Przy wymianie kodu musi pokazać oryginał. Kto ukradł sam kod, nie ma weryfikatora — serwer autoryzacji odmówi. state to losowa wartość zapisana w sesji klienta i odesłana przez IdP; odpowiedź z obcym albo brakującym state nie pasuje do żadnego zapisanego żądania. W OIDC podobną rolę dla ID tokenu pełni nonce.

Zwróć uwagę na niuans: przy wyłączonym state, ale włączonym PKCE, login CSRF i tak się nie udaje. Kod atakującego był wydany dla jego code_challenge, a sesja ofiary trzyma inny weryfikator. RFC 9700 wprost pozwala polegać na PKCE jako ochronie przed CSRF, jeśli masz pewność, że serwer autoryzacji go obsługuje.

Konfiguracja w Spring Security 7. Logowanie OIDC to oauth2Login() plus rejestracja klienta w application.yml. Domyślny adres powrotu to {baseUrl}/login/oauth2/code/{registrationId}.

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((auth) -> auth
            .requestMatchers("/", "/error").permitAll()
            .anyRequest().authenticated())
        .oauth2Login(Customizer.withDefaults());   // żądanie autoryzacji czeka w sesji, PKCE domyślnie
    return http.build();
}
// application.yml
// spring.security.oauth2.client.registration.okta:
//   client-id: web-app
//   client-secret: ${OKTA_SECRET}        # klient poufny
//   authorization-grant-type: authorization_code
//   scope: openid,profile

PKCE w Springu: klient publiczny (bez client-secret, metoda none) dostaje PKCE automatycznie. Dla klienta poufnego decyduje ClientRegistration.clientSettings.requireProofKey — dla authorization_code domyślnie true. Jeśli twój IdP nie obsługuje PKCE dla klientów poufnych, dokumentacja każe ustawić requireProofKey na false — to wyjątek, nie wzorzec.

Zagrożenie. Twoje API przyjmuje nagłówek Authorization: Bearer eyJ…. JWT to trzy części base64url rozdzielone kropkami: nagłówek (np. alg, kid), ładunek z roszczeniami (iss, sub, aud, exp, scope) i podpis. Każdy może token zdekodować i przeczytać. Atakujący chce, żeby twoje API uwierzyło w token, którego nie powinno przyjąć.

Klasyki z RFC 8725: atakujący zmienia alg na none, a biblioteka „weryfikuje” token bez sprawdzania podpisu; zmienia RS256 na HS256, a biblioteka używa publicznego klucza RSA jako sekretu HMAC; albo przynosi prawdziwy token wydany dla innej usługi tego samego IdP (atak podstawienia).

Jak działa ochrona. Gdy podasz issuer-uri, Spring Security dla poprawnie zbudowanego JWT: weryfikuje podpis kluczem pobranym z jwks_uri (i sam obraca klucze), sprawdza exp i nbf (JwtTimestampValidator, z konfigurowalnym clockSkew) oraz iss, a każdy scope zamienia na uprawnienie z prefiksem SCOPE_. Domyślnie NimbusJwtDecoder ufa tylko RS256. Audience nie jest sprawdzane, dopóki go nie skonfigurujesz.

Konfiguracja w Spring Security 7. Najkrócej: issuer-uri i audiences w Boot.

// application.yml
// spring.security.oauth2.resourceserver.jwt:
//   issuer-uri: https://idp.example.com
//   audiences: https://orders.example.com     # bez tego aud NIE jest sprawdzane

@Bean
SecurityFilterChain api(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((auth) -> auth
            .requestMatchers(HttpMethod.GET, "/api/orders/**").hasAuthority("SCOPE_orders:read")
            .anyRequest().authenticated())
        .oauth2ResourceServer((oauth2) -> oauth2.jwt(Customizer.withDefaults()));
    return http.build();
}

// albo programowo: dorzuć walidator aud do domyślnych
@Bean
JwtDecoder jwtDecoder() {
    NimbusJwtDecoder decoder = JwtDecoders.fromIssuerLocation("https://idp.example.com");
    OAuth2TokenValidator<Jwt> audience = new JwtClaimValidator<List<String>>(
            JwtClaimNames.AUD, (aud) -> aud != null && aud.contains("https://orders.example.com"));
    decoder.setJwtValidator(new DelegatingOAuth2TokenValidator<>(
            JwtValidators.createDefaultWithIssuer("https://idp.example.com"), audience));
    return decoder;
}

Odrzucony token kończy się 401 Unauthorized z nagłówkiem WWW-Authenticate: Bearer … i kodem błędu invalid_token; dla alg:none opis brzmi „Unsupported algorithm of none”. Uwaga przy setJwtValidator: zastępujesz domyślne walidatory, więc zawsze startuj od JwtValidators.createDefaultWithIssuer(…), inaczej po cichu tracisz sprawdzanie exp.

Zagrożenie. Twoje SPA dostało access token i — jak w połowie tutoriali — zapisało go w localStorage. Pewnego dnia w komentarzu pod produktem ktoś przemyca skrypt (XSS). Skrypt działa w twoim originie, więc widzi wszystko, co widzi twój kod JavaScript. Atakujący chce tokenu, bo token działa z dowolnego komputera, aż wygaśnie.

Jak działa ochrona. OWASP mówi wprost: nie trzymaj tokenów, identyfikatorów sesji ani JWT w localStorage czy sessionStorage — każdy skrypt w originie je odczyta. Ciasteczko z flagą HttpOnly jest niewidoczne dla document.cookie. Wzorzec BFF (Backend for Frontend) idzie dalej: tokeny OAuth zostają na serwerze, a przeglądarka ma tylko ciasteczko sesji HttpOnly. XSS dalej jest groźny — może wysyłać żądania z karty ofiary — ale nie wyniesie biletu, który działa poza nią.

JWT czy opaque? JWT serwer zasobów sprawdza lokalnie (podpis + roszczenia) — szybko, ale nie da się go odwołać przed exp, bo nikt nie pyta IdP. Token opaque to losowy identyfikator; API pyta o niego endpoint introspekcji przy każdym żądaniu. Dokumentacja Springa podsumowuje: to się przydaje, „when revocation is a requirement”. Krótki TTL JWT to kompromis między jednym a drugim.

// Serwer zasobów z tokenem opaque (introspekcja przy każdym żądaniu)
// spring.security.oauth2.resourceserver.opaquetoken:
//   introspection-uri: https://idp.example.com/introspect
//   client-id: orders-api
//   client-secret: ${INTROSPECT_SECRET}
http.oauth2ResourceServer((oauth2) -> oauth2.opaqueToken(Customizer.withDefaults()));

Zagrożenie. Serwis billing woła orders. Nie ma tu użytkownika, więc serwis loguje się sam sobą: grant client_credentials. Dostaje zwykły bearer token — „na okaziciela”. Jeśli token wycieknie (log z nagłówkami, zrzut ruchu, zhakowany sidecar), atakujący użyje go z dowolnego miejsca, dopóki nie wygaśnie.

Jak działa ochrona. RFC 9700 zaleca tokeny sender-constrained — związane z nadawcą. Dwie drogi: mTLS (RFC 8705) — serwer autoryzacji wpisuje do tokenu odcisk certyfikatu klienta (cnf.x5t#S256), a API sprawdza, czy połączenie TLS przyszło z tym certyfikatem; DPoP (RFC 9449) — token zawiera odcisk klucza publicznego (cnf.jkt), a każde żądanie niesie świeży dowód DPoP: JWT podpisany kluczem prywatnym, z metodą (htm), adresem (htu) i skrótem tokenu (ath). Złodziej ma token, ale nie ma klucza.

Konfiguracja w Spring Security 7. Klient: client_credentials w rejestracji i OAuth2ClientHttpRequestInterceptor w RestClient — interceptor sam pobiera token z Token Endpoint i odnawia go po wygaśnięciu.

// spring.security.oauth2.client.registration.orders-api:
//   client-id: billing
//   client-secret: ${BILLING_SECRET}
//   authorization-grant-type: client_credentials
//   scope: orders:read
@Bean
RestClient ordersClient(OAuth2AuthorizedClientManager manager) {
    return RestClient.builder()
            .baseUrl("https://orders.internal")
            .requestInterceptor(new OAuth2ClientHttpRequestInterceptor(manager))
            .build();
}
// wywołanie: .attributes(clientRegistrationId("orders-api"))

// Serwer zasobów uwierzytelniający certyfikatem klienta (mTLS na poziomie aplikacji)
http.x509(Customizer.withDefaults())          // domyślnie CN z certyfikatu → nazwa użytkownika
    .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated());

Po stronie Spring Authorization Server tokeny związane z certyfikatem włączasz dla klienta przez TokenSettings.builder().x509CertificateBoundAccessTokens(true) (z metodą uwierzytelnienia TLS_CLIENT_AUTH), a DPoP-bound access tokens są obsługiwane jako osobny typ tokenu.

Zagrożenie. Serwer autoryzacji to najcenniejszy cel w całej architekturze: kto go przejmie albo źle skonfiguruje, wydaje bilety do wszystkiego. Typowe wpadki to klient publiczny bez PKCE, zbyt szerokie redirect_uri, klucze podpisu generowane przy każdym starcie (tokeny przestają działać po restarcie) albo trzymane w repozytorium.

Od wersji 7.0 Spring Authorization Server jest częścią Spring Security i — co ważne — ma PKCE włączone domyślnie dla wszystkich klientów używających authorization code (requireProofKey = true). Klient bez code_challenge nie przejdzie.

Jak to jest zbudowane. Kliknij komponenty. Minimalna konfiguracja włącza endpointy autoryzacji, tokenu, introspekcji, odwołania, metadanych i JWK Set (ten ostatni tylko, gdy masz bean JWKSource). OpenID Connect jest domyślnie wyłączony — włączasz go przez .oidc(…).

Konfiguracja w Spring Security 7. Starter spring-boot-starter-oauth2-authorization-server, a w kodzie konfigurator oauth2AuthorizationServer:

@Bean @Order(1)
SecurityFilterChain authorizationServer(HttpSecurity http) throws Exception {
    http
        .oauth2AuthorizationServer((as) -> as.oidc(Customizer.withDefaults()))  // OIDC domyślnie wyłączony
        .authorizeHttpRequests((auth) -> auth.anyRequest().authenticated())
        .formLogin(Customizer.withDefaults());   // authorization_code wymaga zalogowanego użytkownika
    return http.build();
}

@Bean
RegisteredClientRepository clients() {
    RegisteredClient spa = RegisteredClient.withId(UUID.randomUUID().toString())
            .clientId("spa")
            .clientAuthenticationMethod(ClientAuthenticationMethod.NONE)   // klient publiczny
            .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
            .redirectUri("https://app.example.com/callback")              // dokładny adres
            .scope(OidcScopes.OPENID)
            .clientSettings(ClientSettings.builder().requireProofKey(true).build())  // i tak domyślne
            .build();
    return new InMemoryRegisteredClientRepository(spa);   // produkcja: JdbcRegisteredClientRepository
}

Zagrożenie. Tu atakującym jest… zwykły pull request. Ktoś refaktoryzuje reguły, zamienia hasRole("ADMIN") na authenticated() „bo testy nie przechodziły”. Wszystkie testy są zielone, bo każdy sprawdza, że admin może. Żaden nie sprawdza, że zwykły użytkownik nie może.

Jak działa ochrona. Traktuj reguły jak tabelę: każdy endpoint × każda rola → oczekiwany status. Komórki z 401 i 403 to testy negatywne i są równie ważne jak 200. Spring Security Test daje ci do tego cegiełki: @WithMockUser (domyślnie użytkownik user, hasło password, rola ROLE_USER), @WithAnonymousUser, a w MockMvc post-procesory user(…), csrf(), jwt(), oauth2Login().

Kliknij komórkę, żeby zobaczyć wygenerowany test.

Konfiguracja. Z MockMvc (Spring Boot sam dokłada filtry Spring Security w @WebMvcTest/@AutoConfigureMockMvc; ręcznie: .apply(springSecurity())):

@Test
@WithMockUser                       // user / ROLE_USER
void userCannotDeleteOrders() throws Exception {
    mvc.perform(delete("/api/orders/17").with(csrf()))
       .andExpect(status().isForbidden());
}

@Test
void postWithoutCsrfIsRejected() throws Exception {
    mvc.perform(post("/api/orders").with(user("ala").roles("USER")))
       .andExpect(status().isForbidden());           // brak csrf()
}

@Test
void reportsTokenCannotReadOrders() throws Exception {
    mvc.perform(get("/api/orders")
            .with(jwt().authorities(new SimpleGrantedAuthority("SCOPE_reports:read"))))
       .andExpect(status().isForbidden());
}

Domyślnie jwt() tworzy token z jednym uprawnieniem SCOPE_read; nadpisujesz je przez authorities(…) albo roszczenia przez jwt().jwt((jwt) -> jwt.claim(…)). Pamiętaj: post-procesor jwt() omija JwtDecoder, więc walidację aud/iss testuj osobno, na samym dekoderze.

Zagrożenie. Credential stuffing (rozdział o brute force) albo ktoś, kto metodycznie sprawdza /admin/**, zostawia ślady: setki 401 i 403. Jeśli nikt ich nie zbiera, atak trwa tygodniami. A jeśli zbierasz je źle, w logach lądują hasła i tokeny — i log staje się nowym celem.

Jak działa ochrona. Spring Security publikuje zdarzenia. Każde udane i nieudane uwierzytelnienie to AuthenticationSuccessEvent albo zdarzenie porażki (np. AuthenticationFailureBadCredentialsEvent) — w Boot DefaultAuthenticationEventPublisher jest gotowy. Każda odmowa autoryzacji to AuthorizationDeniedEvent. Dokumentacja każe zarejestrować bean AuthorizationEventPublisher (np. SpringAuthorizationEventPublisher); w 7.1 reguły HTTP i tak publikują odmowy przez SpringAuthorizationEventPublisher, a własny bean jest potrzebny m.in. przy zdarzeniach „granted”. AuthorizationGrantedEvent domyślnie nie jest publikowane — byłoby za głośno. Zdarzenia przekazujesz do logu bezpieczeństwa i metryk, a reguła alertu robi resztę.

Konfiguracja w Spring Security 7.

@Bean
AuthorizationEventPublisher authorizationEventPublisher(ApplicationEventPublisher publisher) {
    return new SpringAuthorizationEventPublisher(publisher);   // publikuje AuthorizationDeniedEvent
}

@Component
class SecurityAudit {
    private static final Logger log = LoggerFactory.getLogger("SECURITY");

    @EventListener
    void onSuccess(AuthenticationSuccessEvent e) {
        log.info("auth.success user={}", e.getAuthentication().getName());
    }
    @EventListener
    void onFailure(AbstractAuthenticationFailureEvent e) {
        log.warn("auth.failure user={} reason={}",          // bez hasła, bez tokenu
                e.getAuthentication().getName(), e.getException().getClass().getSimpleName());
    }
    @EventListener
    void onDenied(AuthorizationDeniedEvent<?> e) {
        log.warn("authz.denied user={}", e.getAuthentication().get().getName());
    }
}

Micrometer. Gdy w kontekście jest bean ObservationRegistry, Spring Security sam tworzy obserwacje (trace’y) dla łańcucha filtrów, AuthenticationManager i AuthorizationManager — nazwy spring.security.http.chains, spring.security.authentications, spring.security.authorizations. Z tego masz metryki czasu i błędów bez pisania kodu.

Zagrożenie. W rozdziale o SecurityContextHolder widziałeś, że kontekst siedzi w ThreadLocal i że DelegatingSecurityContextExecutor przenosi go do puli. Teraz gorsze przypadki: kontekst, który znika (kod w tle działa jako „nikt” i ktoś „naprawia” to, wyłączając sprawdzanie), i kontekst, który przecieka — wątek z puli wykonuje zadanie Alicji z tożsamością Bartka.

Jak działa ochrona. InheritableThreadLocal kopiuje wartość w chwili tworzenia wątku, nie w chwili zlecenia zadania — z pulą to loteria. Poprawnie jest przekazać kontekst per zadanie: DelegatingSecurityContextRunnable/Callable albo opakowane executory (DelegatingSecurityContextAsyncTaskExecutor, DelegatingSecurityContextExecutorService…), które ustawiają kontekst przed zadaniem i czyszczą po nim. CompletableFuture.supplyAsync(…) bez executora idzie do ForkJoinPool.commonPool() — tam kontekstu nie ma wcale. W WebFlux zapomnij o ThreadLocal: kontekst płynie w Reactor Context, a czytasz go przez ReactiveSecurityContextHolder.getContext().

Konfiguracja.

// @Async: opakuj executor — kontekst kopiowany przy KAŻDYM zleceniu, czyszczony po nim
@Bean
Executor taskExecutor() {
    ThreadPoolTaskExecutor pool = new ThreadPoolTaskExecutor();
    pool.initialize();
    return new DelegatingSecurityContextAsyncTaskExecutor(pool);
}

// CompletableFuture: zawsze z własnym (opakowanym) executorem
CompletableFuture.supplyAsync(() -> reports.exportFor(currentUser()), securedExecutor);

// WebFlux: kontekst z Reactor Context, nie z ThreadLocal
Mono<String> me = ReactiveSecurityContextHolder.getContext()
        .map((ctx) -> ctx.getAuthentication().getName());

// ŹLE: dziedziczenie przy tworzeniu wątku + pula = cudza tożsamość
SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL);

Zagrożenie. W firmie nie ma jednej aplikacji. Jest brama API, kilkadziesiąt serwisów, wspólna baza i dostawca tożsamości (IdP). Atakujący rzadko forsuje bramę od frontu. Częściej wchodzi bokiem: przez starą bibliotekę w mało ważnym serwisie raportowym, o którym wszyscy zapomnieli.

Gdy już siedzi w środku, chce iść dalej. To się nazywa ruch boczny (lateral movement): z przejętego serwisu woła inne serwisy i bazę tak, jakby był „swój”. Udaje mu się wtedy, gdy wewnątrz sieci wszyscy ufają wszystkim.

Jak działa ochrona. Nie ma jednego magicznego filtra. Jest kilka zasad, które razem zmniejszają promień rażenia (blast radius), czyli to, ile atakujący może zrobić z jednego przejętego miejsca:

• Domyślnie odmawiaj. Każda ścieżka, której nie opisałeś, kończy się odmową: anyRequest().denyAll() albo co najmniej authenticated() (zobacz reguły URL). OWASP nazywa to „deny by default”.
• Jeden dostawca tożsamości (IdP) i SSO. Logowanie, MFA i blokady kont są w jednym miejscu, a serwisy dostają podpisane tokeny (OAuth/OIDC).
• Zero trust. Każdy serwis sam waliduje token: podpis, iss, exp i aud (JWT). Brama to pierwsza linia, nie jedyna.
• Najmniejsze uprawnienia (least privilege): użytkownik bazy per serwis, scope tokenu per operacja, konto techniczne bez praw admina.
• Obrona w głąb (defense in depth): kilka niezależnych warstw. Gdy jedna zawiedzie, następna dalej trzyma.

Zauważ kolejność. Walidacja JWT w serwisie zatrzymuje żądanie z fałszywym nagłówkiem: BearerTokenAuthenticationFilter nie znajduje tokenu i serwis odpowiada 401 z nagłówkiem WWW-Authenticate: Bearer. mTLS zatrzymuje je jeszcze wcześniej, na poziomie połączenia. A minimalne uprawnienia w bazie ograniczają szkody nawet wtedy, gdy hasło do bazy już wyciekło.

Konfiguracja w Spring Security 7

Każdy serwis jest resource serverem: sam sprawdza wydawcę i odbiorcę tokenu. W Spring Boot wystarczą dwie właściwości:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://idp.firma.pl/realms/main   # podpis (JWKS) + iss + exp/nbf
          audiences: billing-service                    # aud musi zawierać ten serwis

Osobny łańcuch na każdą powierzchnię: Actuator dla operacji, API dla klientów. Ostatnia reguła zawsze odmawia.

@Bean
@Order(1)
SecurityFilterChain actuator(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/actuator/**")
        .authorizeHttpRequests((auth) -> auth
            .requestMatchers("/actuator/health").permitAll()
            .anyRequest().hasRole("OPS"))
        .httpBasic(Customizer.withDefaults());
    return http.build();
}

@Bean
@Order(2)
SecurityFilterChain api(HttpSecurity http) throws Exception {
    http
        .securityMatcher("/api/**")
        .authorizeHttpRequests((auth) -> auth
            .requestMatchers(HttpMethod.GET, "/api/invoices/**").hasAuthority("SCOPE_invoices.read")
            .requestMatchers(HttpMethod.POST, "/api/invoices").hasAuthority("SCOPE_invoices.write")
            .anyRequest().denyAll())                        // deny by default
        .oauth2ResourceServer((oauth2) -> oauth2.jwt(Customizer.withDefaults()))
        .sessionManagement((session) -> session
            .sessionCreationPolicy(SessionCreationPolicy.STATELESS));
    return http.build();
}

// ❌ „brama już sprawdziła” — serwis wierzy nagłówkowi
String user = request.getHeader("X-User");
if ("admin".equals(user)) { return invoiceRepository.findAll(); }

Minimalne uprawnienia w bazie to nie Spring, tylko zwykły SQL. Każdy serwis dostaje własnego użytkownika i tylko swój schemat:

CREATE USER reports_ro WITH PASSWORD :'from_vault';
GRANT USAGE  ON SCHEMA reports TO reports_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA reports TO reports_ro;   -- bez DROP, bez billing.*

Każdy atak to łańcuch kroków. Atakujący musi przejść wszystkie, a obrońcy wystarczy przerwać jeden. Dlatego przy każdej obronie pytasz nie tylko „czy działa?”, ale też „w którym kroku działa?”. Im wcześniej, tym mniej szkód.

Wybierz atak, przejdź go krok po kroku z wyłączoną obroną, a potem włącz 🛡️ Obrona. Zobaczysz, w którym kroku i którą klasą albo opcją DSL Spring przerywa łańcuch. Pod spodem jest link do rozdziału, w którym ten mechanizm jest opisany dokładnie.

Popatrz na kolumnę „gdzie zatrzymane”. Część ataków Spring zatrzymuje sam, bo ochrona jest domyślnie włączona: CSRF, nagłówki przeciw clickjackingowi, zmiana ID sesji, StrictHttpFirewall. Część wymaga twojej decyzji: reguły, sprawdzenie właściciela, audience, CORS. A dwa ataki (IDOR i mass assignment) w ogóle nie są „sprawą filtra”. To projekt twojego kodu.

To lista na przegląd przed wdrożeniem albo na pierwszy tydzień w nowym projekcie. Każdy punkt nazywa konkretną opcję Springa, więc możesz go od razu sprawdzić w kodzie. Punkty oznaczone domyślnie Spring robi sam. Twoim zadaniem jest ich nie wyłączyć.

Większość awarii Spring Security wygląda tak samo: 401, 403 albo przekierowanie, którego nikt nie zamawiał. Zanim zaczniesz zgadywać, włącz logging.level.org.springframework.security=TRACE. Log pokaże, który łańcuch pasował, które filtry się wykonały i która reguła odmówiła.

Wybierz rodzaj objawu, a potem kliknij konkretny objaw w tabeli. Dostaniesz pierwszy krok diagnozy.

Rekruter nie chce usłyszeć definicji z Wikipedii. Chce usłyszeć, że wiesz, która klasa to robi, kiedy to się psuje i jaki jest kompromis. Odpowiedzi poniżej są krótkie, ale konkretne. Najpierw odpowiedz na głos, dopiero potem rozwiń.

Każde pytanie testuje mechanizm z jednego rozdziału. Błędne odpowiedzi to typowe mity, które rozdziały obalały. Pytania z dopiskiem (L2) albo (L3) dotyczą głębszych poziomów.

Ściąga