Correct use of WebSecurity in WebSecurityConfigurerAdapter

Your example means that Spring (Web) Security is ignoring URL patterns that match the expression you have defined ("/static/**"). This URL is skipped by Spring Security, therefore not secured.

Allows adding RequestMatcher instances that should that Spring Security should ignore. Web Security provided by Spring Security (including the SecurityContext) will not be available on HttpServletRequest that match. Typically the requests that are registered should be that of only static resources. For requests that are dynamic, consider mapping the request to allow all users instead.

See WebSecurity API documentation for more info.

You can have as many URL patterns secured or unsecured as you want.
With Spring Security you have authentication and access control features for the web layer of an application. You can also restrict users who have a specified role to access a particular URL and so on.

Read the Spring Security reference for more details:
http://docs.spring.io/spring-security/site/docs/current/reference/html/

Ordering Priority of URL Patterns

When matching the specified patterns against an incoming request, the matching is done in the order in which the elements are declared. So the most specific matches patterns should come first and the most general should come last.

There are multiple children to the http.authorizeRequests() method each matcher is considered in the order they were declared.

Patterns are always evaluated in the order they are defined. Thus it is important that more specific patterns are defined higher in the list than less specific patterns.

Read here for more details:
http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#filter-security-interceptor

Example 1

General use of WebSecurity ignoring() method omits Spring Security and none of Spring Security’s features will be available. WebSecurity is based above HttpSecurity
(in an XML configuration you can write this: <http pattern="/resources/**" security="none"/>).

@Override
public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/resources/**")
        .antMatchers("/publics/**");
}

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .antMatchers("/publics/**").hasRole("USER") // no effect
        .anyRequest().authenticated();
}

WebSecurity in the above example lets Spring ignore /resources/** and /publics/**. Therefore the .antMatchers("/publics/**").hasRole("USER") in HttpSecurity is unconsidered.

This will omit the request pattern from the security filter chain entirely. Note that anything matching this path will then have no authentication or authorization services applied and will be freely accessible.

Example 2

Patterns are always evaluated in order. The below matching is invalid because the first matches every request and will never apply the second match:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/**").hasRole("USER")
        .antMatchers("/admin/**").hasRole("ADMIN"):
}