Первое совпавшее правило выигрывает: anyRequest().authenticated() перехватит всё, включая /public/**. В Spring Security 6 такая конфигурация падает при старте — anyRequest обязан стоять последним.
А ещё Отладка — TRACE-логи Spring Security
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Правила авторизации образуют упорядоченный список, и Spring Security применяет первое, чей матчер подошёл к запросу — специфичность роли не играет. Поэтому порядок пишут от частного к общему, а anyRequest ставят завершающим. В свежих версиях Spring Security подобная ошибка обычно ловится при старте с сообщением о недостижимом правиле, но полагаться на это не стоит. Хорошая практика — завершать цепочку именно anyRequest().authenticated() или denyAll(), реализуя принцип запрета по умолчанию: новый эндпоинт тогда закрыт, пока для него явно не описано правило.
Один верный вариант. Подумайте, потом откройте ответ.
SecurityFilterChain, аутентификация (UserDetailsService/PasswordEncoder), SecurityContext, авторизация запросов и CSRF/CORS/сессии.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto