Yes. Spring Security's AuthorizationFilter processes your request matcher and rule pairs in the order listed and applies only the first match. Put specific rules first, broad rules later, and finish with a catch all that requires authentication or denies the request. A broad permit rule placed early can open routes you meant to protect.
How matching works
The reference describes each declaration as a pattern and rule pair. It says the filter works through the pairs in order and applies only the first match, and gives an example where a rule for one endpoint comes before a rule for everything else. The reading it suggests is: if the request is that endpoint, require the user authority, else only require authentication.
So order is meaning. Swap those two rules and the specific one would never run.
A safe layout
| Position | Kind of rule | Example intent |
|---|---|---|
| First | Narrow, high risk | Admin and management paths require a role |
| Middle | Public or semi public | Login page, static assets, health probe |
| Last | Catch all | Anything else requires authentication |
The reference's simplest setup is a single rule telling Spring that any endpoint requires an authenticated security context. That is a good last line even in a large config.
Steps to review a config
- Read the rules from the top, and for each one ask which routes it captures completely.
- Move any permit all rule below the rules for sensitive paths.
- Check that the last rule is a catch all. If it is missing, requests that match nothing may be handled differently from what you expect, so state the intent explicitly.
- Watch for patterns that look narrow but are not, such as a wildcard directly under a sensitive prefix.
- Use the framework's test support, which the reference demonstrates with mock users, to prove that an unauthenticated call is rejected and a wrong role gets forbidden.
- Re-test after adding any servlet mapping, because the docs list matching in setups where Spring MVC is mapped somewhere other than the default servlet as its own topic.
Why it matters for scanners
Route level authorization mistakes are not library vulnerabilities, so a dependency scanner cannot see them. Dynamic testing or tests in your own suite catch them. A good habit is a table of routes and expected status codes for anonymous, user and admin callers, run in CI.
Relatedly, if you use Actuator, read which endpoints your chain covers.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
What if two rules both match?
Only the first one in the list applies. Later matches are ignored for that request.
Is a final catch all rule required?
It is not required to compile, but it is good practice so your intent for unmatched requests is explicit.
Sources
Last reviewed: 19 October 2026.
