A request matcher identifies the HTTP requests to which Spring Security applies a rule. In endpoint authorization, requestMatchers() selects requests by path, optionally including the HTTP method, before a rule such as hasRole(), authenticated(), permitAll(), or denyAll(). section 8.0 section 8.1
Choose the matcher form that fits the restriction:
- Use requestMatchers(String... patterns) when authorization depends only on paths; the restriction applies to any HTTP method using those paths. section 8.2
- Use requestMatchers(HttpMethod method, String... patterns) when the same path needs different rules for GET, POST, PUT, or DELETE. section 8.2
- Use ANT-style path expressions: * matches one pathname, ** matches multiple pathnames, and {param:regex} constrains a path variable. section 8.2
- Use RegexRequestMatcher when path expressions cannot express the requirement, while recognizing that regexes are more powerful but harder to read. section 8.3
Role and method-specific endpoint rules
A security chain can require ADMIN for /hello and MANAGER for /ciao, producing HTTP 403 for the wrong authenticated role. It can also require authentication for GET /a, permit POST /a, and deny other requests. section 8.1 section 8.2
Matcher order and fallback rules determine the effective policy. anyRequest() refers to all requests, or to any request not selected earlier; permitAll() makes the fallback public, while authenticated() requires login. section 8.0 section 8.1
The same contract can target CSRF exclusions. ignoringRequestMatchers() accepts path expressions or a RequestMatcher such as MvcRequestMatcher or RegexRequestMatcher, allowing rules to include HTTP methods and regexes. section 9.3
Regex-constrained paths
The pattern /product/{code:^[0-9]*$} permits unauthenticated access only when code contains digits. A regex matcher can also permit /email/{email} values ending in .com and deny other requests. section 8.2 section 8.3
