Твой запрос не попадает напрямую в контроллер. Он проходит через цепочку фильтров — Filter Chain. Это основа Spring Security.

Когда HTTP-запрос попадает в Java-приложение, он никогда не идет напрямую в контроллер. Сначала он проходит через Filter Chain — упорядоченную последовательность фильтров, которые могут проверить, изменить или заблокировать запрос до того, как выполнится твой код.

Эта идея пришла из Servlet API. Фильтр реализует метод doFilter(request, response, chain). Внутри можно сделать предобработку (например, логирование или проверку заголовков), вызвать chain.doFilter(request, response), чтобы передать запрос дальше, или прервать выполнение, фактически заблокировав запрос (например, вернув 403 Forbidden).

Spring Security расширяет это через FilterChainProxy, который управляет одним или несколькими SecurityFilterChains. Каждая цепочка применяется к своим URL-паттернам и содержит строго упорядоченный набор фильтров.

Примеры:

• Аутентификационные фильтры (например, UsernamePasswordAuthenticationFilter или кастомный JWT-фильтр) определяют личность пользователя.
• Фильтр авторизации проверяет права и роли.
• Фильтр управления сессией отвечает за логин-сессии.
• CSRF-фильтр защищает от подделки запросов.
• Фильтр перевода исключений гарантирует, что ошибки безопасности вернут правильный ответ.

Порядок имеет значение: аутентификация должна происходить раньше авторизации, CSRF-проверка — до обработки запроса, а обработка исключений должна оборачивать всю цепочку. Поэтому Spring предоставляет методы addFilterBefore и addFilterAfter для кастомизации.

Только после прохождения всех нужных проверок запрос попадает в контроллер.

Простой поток:
Request → Filter Chain → Controller → Response → Filter Chain → Client

👉 Java Portal