JavaNotes

Безопасность приложения Spring Security

2 min read

Spring Security

В servlet-приложении Spring Security — цепочка filters перед DispatcherServlet. Она извлекает данные аутентификации, создаёт Authentication, сохраняет SecurityContext и проверяет доступ.

Аутентификация и авторизация

  • аутентификация отвечает «кто это?»;
  • авторизация отвечает «может ли он выполнить действие?»;
  • Principal/Authentication представляет текущего субъекта;
  • GrantedAuthority — право, используемое в проверках.
request
 → SecurityFilterChain
 → authentication filter
 → AuthenticationManager
 → AuthenticationProvider
 → SecurityContext
 → authorization
 → DispatcherServlet

Современная конфигурация

@Bean
SecurityFilterChain apiSecurity(HttpSecurity http) throws Exception {
    return http
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/health").permitAll()
            .anyRequest().authenticated()
        )
        .httpBasic(Customizer.withDefaults())
        .build();
}

Старый WebSecurityConfigurerAdapter и переопределение configure больше не являются основным подходом. См. Метод configure Spring Security.

Session и token

Cookie с session id и bearer token — разные способы перенести учётные данные. JWT не означает автоматическую отзывчивость, шифрование или безопасность: подпись подтверждает целостность, а срок, аудитория и issuer должны проверяться.

Для браузера важно учитывать CSRF. Если браузер автоматически прикладывает cookie, state-changing запрос нуждается в защите. Для stateless API с bearer token в Authorization, который клиент добавляет явно, модель риска иная.

Защита

  • пароли хранить через PasswordEncoder;
  • ограничивать доступ правилом deny-by-default;
  • проверять права на уровне URL и метода там, где нужно;
  • не логировать токены, пароль и session id;
  • очищать security context между запросами;
  • различать 401 и 403;
  • тестировать негативные сценарии.

Вопросы для повторения

  1. Где работает Spring Security MVC-приложения? В servlet filter chain до controller.
  2. Чем 401 отличается от 403? 401 — нет приемлемой аутентификации, 403 — субъект известен, но доступ запрещён.
  3. JWT зашифрован? Обычно нет, содержимое base64url-кодировано и подписано.
  4. Когда нужен CSRF? Когда браузер автоматически отправляет учётные данные, например session cookie.
  5. Что хранит SecurityContext? Authentication текущего выполнения.

Связано: Фильтры Filters слушатели Listeners и перехватчики Interceptors, Контроллеры Spring.

Graph View

Backlinks