Spring Framework, and, more precisely, the Spring Security component, allows setting up access control checks at the URI level. This is done by adding request matchers to the security configuration, each authorizing access to some resources depending on the incoming request entitlement.

Similarly to firewall filtering rules, the order in which those matchers are defined is security relevant.

Why is this an issue?

Configured URL matchers are considered in the order they are declared. Especially, for a given resource, if a looser filter is defined before a stricter one, only the less secure configuration will apply. No request will ever reach the stricter rule.

This rule raises an issue when:

A URL pattern ending with ** precedes another one having the same prefix. E.g. /admin/** is defined before /admin/example/**
A pattern without wildcard characters is preceded by another one that matches it. E.g.: /page-index/db is defined after /page*/**

What is the potential impact?

Access control rules that have been defined but cannot be applied generally indicate an error in the filtering process. In most cases, this will have consequences on the application’s authorization and authentication mechanisms.

Authentication bypass

When the ignored access control rule is supposed to enforce the authentication on a resource, the consequence is a bypass of the authentication for that resource. Depending on the scope of the ignored rule, a single feature or whole sections of the application can be left unprotected.

Attackers could take advantage of such an issue to access the affected features without prior authentication, which may impact the confidentiality or integrity of sensitive, business, or personal data.

Privilege escalation

When the ignored access control rule is supposed to verify the role of an authenticated user, the consequence is a privilege escalation or authorization bypass. An authenticated user with low privileges on the application will be able to access more critical features or sections of the application.

This could have financial consequences if the accessed features are normally accessed by paying users. It could also impact the confidentiality or integrity of sensitive, business, or personal data, depending on the features.

How to fix it in Spring

Code examples

The following code is vulnerable because it defines access control configuration in the wrong order.

Noncompliant code example

protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
      .antMatchers("/resources/**", "/signup", "/about").permitAll()
      .antMatchers("/admin/**").hasRole("ADMIN")
      .antMatchers("/admin/login").permitAll() // Noncompliant
      .antMatchers("/**", "/home").permitAll()
      .antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')") // Noncompliant
      .and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
  }

Compliant solution

  protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
      .antMatchers("/resources/**", "/signup", "/about").permitAll()
      .antMatchers("/admin/login").permitAll()
      .antMatchers("/admin/**").hasRole("ADMIN")
      .antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")
      .antMatchers("/**", "/home").permitAll()
      .and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
  }