По фреймворкам
Безопасность Spring Boot — референс по продакшн-закалке
Референс по продакшн-закалке Spring Boot: приоритетный чек-лист плюс CVE зависимостей (Log4Shell), продакшн-конфиг/секреты, авторизация Spring Security, экспозиция Actuator, десериализация и SSRF. Защитно, без шагов атаки.
Для тех, кто эксплуатирует приложение на Java / Spring Boot. Здесь нет шагов атаки — это рабочий референс по закалке: приоритетный чек-лист, руководство по областям и самопроверка. Полную картину по фреймворкам смотрите в хабе по безопасности для каждого фреймворка.
Чек-лист закалки по приоритету
Прорабатывайте таблицу сверху вниз. P0 — предпосылка, P1 — самый частый источник инцидентов, P2 — постоянная эксплуатационная гигиена.
P0 ── Предпосылка (сначала)
Мониторинг CVE зависимостей + быстрое патчение / без деталей ошибок в продакшне / вынос секретов наружу
P1 ── Главный источник инцидентов
Авторизация Spring Security (default-deny, проверки владельца) / сокращение экспозиции Actuator и управления
P2 ── Эксплуатационная гигиена
Небезопасная десериализация / заголовки, CSRF, сессия / SSRF
| Приоритет | Контроль | Специфика (Spring Boot) |
|---|---|---|
| P0 | Мониторинг CVE зависимостей | osv-scanner / dependency-check; судите по работающей версии, быстро патчите (класс Log4Shell) |
| P0 | Продакшн-ошибки | Не поставляйте stack traces (server.error.include-stacktrace=never и т.п.) |
| P0 | Вынос секретов наружу | Данные подключения/ключи из env/Vault, а не хардкод в конфиге. Не коммитьте в репозиторий |
| P1 | Явная авторизация | Default-deny + method security (@PreAuthorize) + проверки владельца |
| P1 | Сокращение экспозиции Actuator | Минимальная экспозиция (например, health) + обязательная аутентификация + отдельный порт/граница. Не открывайте env/heapdump |
| P1 | Десериализация | Не десериализуйте нативно недоверенные данные. Не позволяйте SpEL вычислять ввод |
| P2 | Инъекции | Привязывайте через JPA/JdbcTemplate. Никогда не стройте запросы конкатенацией строк |
| P2 | Заголовки/CSRF/сессия | Заголовки безопасности Spring Security (HSTS и т.п.), CSRF, атрибуты cookie, фиксация сессии |
| P2 | SSRF | Allowlist для серверных запросов + блокировка внутренних IP/метаданных |
1. CVE зависимостей и экосистема (P0)
Именно потому, что Spring так широко используется, изъян библиотеки-зависимости каскадит на всех разом. Log4Shell — символ этого.
- Машинно мониторьте CVE зависимостей через osv-scanner или OWASP dependency-check, судите по работающей версии и быстро патчите (решайте по тому, что реально собрано, а не по объявлению в pom.xml/gradle).
- Держите Spring Boot и Java на поддерживаемых версиях. Не оставляйте EOL-версии.
- Случай и практику смотрите в разборе Log4Shell · плейбуке реагирования на уязвимости · мониторинге CVE зависимостей.
2. Продакшн-конфиг и секреты (P0)
- В продакшне не поставляйте детали ошибок (stack traces) — сокращайте подсказки, которые утекают внутреннюю структуру и версии зависимостей.
- Держите секреты вроде данных подключения и ключей вне application.properties/yml, внедряя их из env или менеджера секретов (Vault и т.п.). Не коммитьте их в репозиторий (→ файлы .env и секреты).
- Не включайте инструменты разработки (devtools и т.п.) в продакшне.
3. Авторизация Spring Security (P1 — главный источник)
Частое (опасно)
- свободные значения по умолчанию, не спроектированы как явное разрешение
- защита только URL-шаблонами, без проверки метода/владельца
- аутентифицирован, но «залогинен = можно»
- пробел в настройке пропускает какую-то конечную точку
Правильно
- default-deny (проходит только то, что вы явно разрешили)
- авторизация метода (
@PreAuthorizeи т.п.) + проверки владельца - проверяйте право/владельца на каждом пути чтения/обновления/удаления
- стройте авторизацию явно, не оставляйте на значения по умолчанию
Смотрите что такое IDOR. Аутентификация и авторизация — разное; авторизуйте близко к данным.
4. Actuator и конечные точки управления (P1)
- Ограничьте открытые конечные точки Actuator до минимума (например, только health).
- Требуйте аутентификацию/авторизацию и держите их на отдельном порту / сетевой границе, недостижимой снаружи.
- Не открывайте чувствительные конечные точки вроде
env,heapdumpилиloggers(утечка информации / плацдарм для операций).
5. Небезопасная десериализация и вычисление выражений (P2)
- Не десериализуйте нативно недоверенные данные (при определённых условиях это может привести к RCE). Проверяйте происхождение и, где нужно, ограничивайте безопасным форматом вроде JSON (→ что такое RCE).
- Не позволяйте шаблонам или SpEL вычислять пользовательский ввод. Валидируйте ввод через Bean Validation и т.п.
6. Инъекции и доступ к данным (P2)
- SQL: привязывайте через JPA / JdbcTemplate; никогда не стройте запросы конкатенацией строк (→ что такое SQL-инъекция).
- Выводя HTML из шаблона, выполняйте кодирование вывода и не встраивайте пользовательский ввод напрямую (защита от XSS).
7. Заголовки, HTTPS, сессия (P2)
- Используйте заголовки безопасности Spring Security (HSTS на HTTPS и т.п.). Проверьте собственный сайт проверкой заголовков безопасности.
- Принудительно используйте HTTPS. За балансировщиком настройте определение правильной схемы/IP клиента.
- Ставьте Secure/HttpOnly/SameSite на cookie, сохраняйте защиту CSRF (включена по умолчанию для браузерных сессий; если отключаете её для API, дополняйте альтернативной защитой) и пересоздавайте сессию при входе.
8. SSRF и серверные запросы (P2)
- Серверная выборка URL, поданных пользователем, должна ограничивать цели allowlist'ом и блокировать доступ к внутренним IP / метаданным облака на этапе подключения (→ что такое SSRF).
Проверьте: ваш Spring Boot действительно закалён?
Построить — не конец; готово только когда вы проверили. Это защитные самопроверки против вашей же среды.
Actuator не открывает чувствительные конечные точки
/actuator не открывает env/heapdump и т.п. и что он аутентифицирован.Ошибки не утекают внутренности
Авторизация держится
Зависимости и заголовки
Взгляд нашего сайта: на закалённом фундаменте решают зависимости и поверхность
Spring — надёжный фундамент, но именно потому, что он так широко используется, изъян библиотеки-зависимости каскадит на всех разом. Log4Shell — символ этого, и основная защита — не столько конкретная настройка, сколько операционная привычка машинно мониторить зависимости, судить по работающей версии и быстро патчить. Наряду с этим держите удобные конечные точки управления (Actuator) вне публичной поверхности и не оставляйте авторизацию на значения по умолчанию. Наш сайт на другом стеке, но принцип идентичен — свежесть зависимостей, минимальная публичная поверхность, явная авторизация работают независимо от фреймворка.
Читать дальше
- Хаб: безопасность по фреймворкам · безопасность Next.js
- Случай/практика: разбор Log4Shell · плейбук реагирования на уязвимости · мониторинг CVE зависимостей
- Глоссарий: что такое IDOR · что такое RCE · что такое SSRF
- Инструменты: проверка заголовков безопасности
FAQ
QЧто сделать в первую очередь, чтобы защитить Spring Boot?
Три пункта P0: (1) машинно мониторьте CVE зависимостей и быстро патчите, судя по работающей версии (с Log4Shell изъян фундаментальной библиотеки каскадит на множество приложений разом, поэтому важно не отставать); (2) не поставляйте подробные ошибки (stack traces) в продакшн; (3) выносите секреты (данные подключения, ключи) наружу, а не хардкодьте их в конфиге. Дальше переходите к авторизации Spring Security и сокращению экспозиции Actuator.
QНа что обращать внимание в Actuator?
Actuator предоставляет конечные точки управления для сведений о работе и диагностики, но при экспозиции может утекать внутренняя информация, а в зависимости от настройки стать плацдармом для операций. В продакшне ограничивайте экспозицию до минимума (например, только health), требуйте аутентификацию и авторизацию и держите на отдельном порту / сетевой границе, недостижимой снаружи. Не поставляйте чувствительные конечные точки вроде env, heapdump или loggers.
QКак подготовиться к изъяну зависимости вроде Log4Shell?
Log4Shell — классический случай, когда изъян широко наследуемой библиотеки логирования каскадом задел множество приложений разом. Основная подготовка — машинно мониторить CVE зависимостей и быстро патчить, судя по работающей версии (osv-scanner, OWASP dependency-check и т.п.) — решать по версии, реально собранной, а не по объявлению в pom.xml/gradle. Минимальные привилегии и сетевая сегментация тоже сокращают радиус поражения.
QКак безопасно писать авторизацию Spring Security?
Склоняйте значение по умолчанию к запрету (проходит только то, что вы явно разрешили), не полагайтесь на одни только URL-шаблоны и используйте авторизацию на уровне метода (@PreAuthorize и т.п.), где уместно. Поверх входа (аутентификации) реализуйте проверку владельца — что целевой ресурс действительно принадлежит пользователю. Пробелы в настройке становятся дырами для повышения привилегий, поэтому стройте авторизацию явно.
QЧем опасна небезопасная десериализация?
Восстановление недоверенных данных через нативную десериализацию Java может при определённых условиях привести к удалённому выполнению кода (RCE). Не восстанавливайте данные из внешнего источника как есть — проверяйте происхождение и, где нужно, ограничивайте безопасным форматом вроде JSON. Точно так же не позволяйте шаблонам или языку выражений (SpEL) вычислять пользовательский ввод.