A security rule is a declarative condition that assigns security requirements to matching URL paths or patterns. In Spring Security, rules commonly decide whether requests require authentication, a role, an authority, or unrestricted access. section 5.3.1 section 5.3
Rules are declared through a SecurityFilterChain bean. HttpSecurity acts as the builder, and build() creates the filter chain that applies the configured requirements to web requests. section 5.3
A rule can express requirements such as:
- hasRole("USER") allows access only to users with the USER role; hasRole() supplies the ROLE_ prefix automatically. section 5.3.1
- authenticated() requires an authenticated user, while permitAll() allows every user to access the matching request. section 5.3 section 5.3.1
- access() accepts a Spring Expression Language expression when conditions need more flexibility than the standard authorization methods provide. section 5.3.1
Protecting design and order pages
A Taco Cloud application can require ROLE_USER for /design and /orders while leaving other requests open. The specific rules must come first because earlier rules take precedence: @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { return http .authorizeRequests() .antMatchers("/design", "/orders").hasRole("USER") .antMatchers("/", "/**").permitAll() .and() .build(); } Reversing these matchers would apply permitAll() first and make the protected-path rule ineffective. section 5.3.1
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http
.authorizeRequests()
.antMatchers("/design", "/orders").hasRole("USER")
.antMatchers("/", "/**").permitAll()
.and()
.build();
}
View the complete SecurityFilterChain configuration for role-protected and public URL paths. section 5.3.1
