How do you design authorization across multiple SecurityFilterChains, and what default-deny practices apply to authorizeHttpRequests?

## Two levels of matching There are **two distinct matcher stages**: 1. **`http.securityMatcher(...)`** — selects which requests a *whole* `SecurityFilterChain` handles. Spring picks the **first** chain (by `@Order`) whose `securityMatcher` matches; that chain alone processes the request. 2. **`authorizeHttpRequests` → `requestMatchers(...)`** — inside the chosen chain, per-rule authorization (first-match-wins, covered elsewhere). Confusing these is a common architecture mistake: `securityMatcher` decides *which chain*, `requestMatchers` decides *access within that chain*. ## Multiple SecurityFilterChain beans Define several beans and order them: ```java @Bean @Order(1) SecurityFilterChain apiChain(HttpSecurity http) throws Exception { http.securityMatcher("/api/**") .authorizeHttpRequests(a -> a .requestMatchers("/api/public/**").permitAll() .anyRequest().authenticated()) .csrf(csrf -> csrf.disable()) // stateless API .sessionManagement(s -> s.sessionCreationPolicy(STATELESS)) .oauth2ResourceServer(o -> o.jwt(withDefaults())); return http.build(); } @Bean @Order(2) SecurityFilterChain webChain(HttpSecurity http) throws Exception { http // no securityMatcher => matches everything else (catch-all chain) .authorizeHttpRequests(a -> a .requestMatchers("/", "/login", "/assets/**").permitAll() .anyRequest().authenticated()) .formLogin(withDefaults()); return http.build(); } ``` Key points: - Lower `@Order` = higher priority; the API chain is checked first, the web chain acts as the fallback (no `securityMatcher` = matches all). - Only **one** chain runs per request. The web chain's rules never apply to `/api/**` and vice versa. So each chain needs its **own** complete authorization policy including its own `anyRequest()`. - Different chains can have different authentication (JWT vs form), CSRF, and session policies — that's the main reason to split. ## Default-deny discipline **Fail closed, not open.** Practices: - End every chain's `authorizeHttpRequests` with `anyRequest().authenticated()` or `anyRequest().denyAll()`. Never rely on the absence of a rule. - Prefer an allowlist: explicitly `permitAll()` the small set of public endpoints; everything else requires auth. - Remember the historical hazard: if no rule matches and there is no `anyRequest()`, the delegating manager grants access. `anyRequest()` removes that ambiguity. - Use `denyAll()` for endpoints that must never be reachable through a given chain (e.g. internal actuator endpoints not exposed). ## Defense in depth URL-based rules are coarse. Combine with **method security** (`@EnableMethodSecurity` + `@PreAuthorize`, `@PostAuthorize`) so authorization is enforced at the service/controller method too — protecting against routing mismatches and internal callers. Both are backed by the same `AuthorizationManager` abstraction in Spring Security 6. ## Matcher hygiene at scale - Keep chain `securityMatcher`s non-overlapping or intentionally ordered; overlapping matchers with wrong `@Order` route requests to the wrong policy. - Use MVC-aligned matchers (`MvcRequestMatcher`) to prevent trailing-slash/variant bypass. - Beware the DispatcherServlet-path ambiguity error and disambiguate with servlet paths. ## Testing as an invariant Rule ordering and default-deny are security invariants — assert them. Use `@WebMvcTest` / `MockMvc` with `spring-security-test` to check that protected URLs return 401/403 for anonymous/under-privileged users and 200 for authorized ones. This catches shadowing bugs and accidental `permitAll()`. ## When to use one vs many chains - **One chain** — a single, uniform auth model (e.g. all form login). - **Multiple chains** — mixed auth models (API tokens + browser sessions), different CSRF/session needs, or clean separation of concerns. Don't over-split; each chain is a full policy to maintain.