Your example mean that Spring (Web) Security is ignoring Url-Pattern that match the Expression you have defined ("/static/**"). This Url is skipped by Security, therefore non-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.

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.

Example 1
Generell use of WebSecurity ignoring() Method omits Spring Security and none of Spring Security’s features will be available.
WebSecurity is based above HttpSecurity. In Xml-Configuration you can write <http pattern="/resources/**" security="none"/>.

WebSecurity in the above example let Spring ignoring /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: