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.
