What is the authorizeHttpRequests DSL in Spring Security, and how do you use requestMatchers with permitAll and authenticated?
answer
- requestMatchers → access rule → anyRequest
- permitAll / authenticated / denyAll
- replaced authorizeRequests() in SS6
- builds AuthorizationFilter
- hasRole adds ROLE_ prefix
basics
~10 sauthorizeHttpRequests is where you declare which URLs need authorization. You list rules with requestMatchers(path) and choose an access rule like permitAll() (open to everyone) or authenticated() (must be logged in).
solid answer
~40 sauthorizeHttpRequests is the method on HttpSecurity where you configure URL-based access control in the SecurityFilterChain. Inside it you register rules: each requestMatchers("/path") is followed by an access decision such as permitAll(), authenticated(), denyAll(), hasRole(...), or hasAuthority(...). You almost always end with anyRequest() to give every unmatched request a default rule. It replaced the older authorizeRequests() (removed in Spring Security 6). Under the hood it builds an AuthorizationFilter backed by an AuthorizationManager. A typical setup permits static/login endpoints, requires authentication for API paths, and denies everything else by ending with anyRequest().authenticated() or denyAll(). Getting the rule set right matters because a missing anyRequest() or a wrong matcher can leave endpoints unintentionally open.
code
java · 12 lines@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/", "/login", "/css/**").permitAll()
.requestMatchers("/api/**").authenticated()
.requestMatchers("/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
)
.formLogin(withDefaults());
return http.build();
}go deeper
Must know the trio permitAll/authenticated/denyAll and that anyRequest is the catch-all.
Should know it replaced authorizeRequests and configures the AuthorizationFilter.
Should explain the AuthorizationManager backing and the ROLE_ prefix semantics.
Frames it as declarative authz policy at the chain level, distinct from method security and matcher strategy choices.
## What it is `authorizeHttpRequests` is a configuration block on `HttpSecurity` used inside a `SecurityFilterChain` bean. It defines **authorization** rules — *who is allowed to access which URLs* — as opposed to **authentication** (proving who you are). It is the modern replacement for the deprecated/removed `authorizeRequests()` (gone in Spring Security 6). ## Core building blocks - **`requestMatchers(...)`** — selects a set of HTTP requests, usually by path (e.g. `"/api/**"`), optionally by HTTP method (`HttpMethod.POST, "/api/**"`). Each call returns an object on which you chain exactly one access rule. - **Access rules** (the terminal you chain after a matcher): - `permitAll()` — allow everyone, authenticated or not. - `denyAll()` — deny everyone, always. - `authenticated()` — must be an authenticated (logged-in) principal, i.e. not anonymous. - `hasRole("ADMIN")` — must have `ROLE_ADMIN` (Spring adds the `ROLE_` prefix for you). - `hasAuthority("SCOPE_read")` — must have that exact authority (no prefix added). - `hasAnyRole(...)`, `hasAnyAuthority(...)`, `access(AuthorizationManager)` for custom logic. - **`anyRequest()`** — a catch-all matcher that matches every request not already matched. You typically place it last. ## Terms defined - **`SecurityFilterChain`** — a Spring bean describing how one set of requests is secured; built from `HttpSecurity`. - **`HttpSecurity`** — the builder you configure (CSRF, CORS, login, authorization, etc.). - **Authenticated vs anonymous** — an unauthenticated user is represented by an `AnonymousAuthenticationToken`; `authenticated()` rejects it, `permitAll()` accepts it. ## How it executes The DSL configures an `AuthorizationFilter` in the filter chain, backed by a `RequestMatcherDelegatingAuthorizationManager`. On each request that filter walks your rules **top to bottom** and applies the **first matching** rule's `AuthorizationManager`. If the decision is deny, it throws `AccessDeniedException` (403) for authenticated users or triggers the entry point (e.g. 401 / redirect to login) for anonymous ones. ## When to use which rule - Public assets, health checks, login/registration pages → `permitAll()`. - Everything behind login → `authenticated()`. - Role/scope-gated admin areas → `hasRole` / `hasAuthority`. - Endpoints you never want reachable via this chain → `denyAll()`. ## Gotchas - Always add `anyRequest()` — if a request matches no rule the framework can leave it effectively unprotected (or behavior is surprising). Ending with `anyRequest().authenticated()` or `.denyAll()` is the safe default. - Rules are order-sensitive (first match wins) — a broad matcher before a specific one shadows the specific one. - `hasRole("X")` expects the authority `ROLE_X`; mixing this up is a common bug.
- What replaced authorizeRequests(), and why should you prefer the new method?authorizeHttpRequests replaced authorizeRequests (removed in Spring Security 6). It uses the AuthorizationManager API, which is more composable/testable and unifies web and method security, whereas the old one used the legacy voter/AccessDecisionManager stack.
- What is the difference between hasRole("ADMIN") and hasAuthority("ADMIN")?hasRole("ADMIN") checks for the authority ROLE_ADMIN (the ROLE_ prefix is added automatically), while hasAuthority("ADMIN") checks for the literal authority ADMIN with no prefix.