Безопасность по фреймворкам

У WordPress крупнейшая доля, поэтому он статистически крупнейшая цель. Входы — не столько ядро, сколько уязвимости плагинов/тем, пропущенные обновления, слабые/переиспользуемые администраторы и открытые поверхности администрирования (wp-admin/xmlrpc/перечисление через REST). Защита: автоматизировать обновления ядра и плагинов, удалять неиспользуемые плагины/темы, надёжный пароль + 2FA для администраторов, ограничить доступ к админке и число попыток входа, обнаружение подмены плюс офлайн-резервные копии.

Laravel поставляется с довольно безопасными настройками по умолчанию, но большинство инцидентов приходит из эксплуатации. Большая тройка ловушек: (1) .env или файлы секретов достижимы по URL из публичного каталога, (2) APP_DEBUG=true в проде раскрывает переменные окружения и данные подключения на странице ошибки, (3) отсутствие авторизации (вход = аутентификация, но нет авторизации по владельцу / Mass Assignment перезаписывает непреднамеренные поля). Защита: секреты вне public с правами 600, отладка выключена + кеш конфигурации в проде, авторизация через Policy/Gate, объявление $fillable.

Next.js поставляется с довольно безопасными значениями по умолчанию, но инциденты происходят на границе сервер/клиент. Большая тройка: (1) утечка переменных окружения (неверное использование NEXT_PUBLIC_ или передача серверных секретов клиенту), (2) отсутствие авторизации в Server Actions / Route Handlers (аутентифицирован, но нет проверки владельца) и (3) известные CVE зависимостей (включая RCE в ядре фреймворка — судите по работающей версии и быстро патчите). Защита: держите секреты на сервере, следите за границей, авторизуйте в каждом действии, машинно мониторьте CVE зависимостей.

Express минималистичен — из коробки он почти не несёт функций безопасности, поэтому защиту добавляет разработчик. Главное: (1) заголовки безопасности (уровня helmet), (2) валидация и санитизация ввода, (3) авторизация по владельцу, а не только аутентификация, (4) ограничение частоты (перебор / DoS), (5) мониторинг CVE зависимостей (npm) и быстрое закрытие. Плюс защита от SSRF при исходящих запросах к URL и секреты в переменных окружения, вне кода. Свобода минимального фреймворка идёт вместе с ответственностью за защиту.

Spring (Spring Boot) — корпоративный стандарт. Типы инцидентов: (1) известные CVE зависимостей (широко наследуемый изъян фундамента, как Log4Shell — судите по работающей версии и быстро патчите), (2) открытые конечные точки управления/диагностики вроде Actuator (утечка информации / операции), (3) отсутствие авторизации Spring Security (аутентифицирован, но слабые проверки прав), (4) небезопасная десериализация. Защита: машинно мониторьте CVE зависимостей и быстро патчите, закрывайте поверхности управления Actuator, делайте авторизацию явной, не десериализуйте недоверенные данные.

Django идёт «с батарейками» и с безопасными значениями по умолчанию (ORM, CSRF, авто-экранирование в шаблонах, auth) и надёжен при корректной настройке. Но инциденты приходят из настроек. Большая тройка: (1) DEBUG=True в проде раскрывает настройки, переменные окружения и секреты на странице ошибки, (2) утёкший SECRET_KEY (основа подписи/сессий), (3) слабая авторизация (нет проверок is_staff/permission). Плюс SQLi через raw()/extra() или интерполяцию строк, небезопасная десериализация (pickle), незаданный ALLOWED_HOSTS и CVE зависимостей (pip). Защита: DEBUG=False в проде, SECRET_KEY из окружения, явная авторизация.

Rails поставляется с соглашениями и безопасными значениями по умолчанию (защита от CSRF, Strong Parameters, ORM) и надёжен при корректном использовании. Но инциденты приходят из эксплуатации. Большая тройка: (1) слишком широкие Strong Parameters, допускающие Mass Assignment (перезапись is_admin и т. п.), (2) слабая авторизация (вход = аутентификация, но нет области владельца), (3) известные CVE gem'ов (зависимостей). Плюс SQLi через интерполяцию строк в where, опасные динамические методы (send/constantize) и утечка credentials/secret_key_base. Защита: сузить permit, сделать авторизацию явной, мониторить CVE gem'ов.

ASP.NET Core — зрелая, надёжная основа, но инциденты приходят из настроек. Большая тройка: (1) раскрытие подробных ошибок / Developer Exception Page в проде (утечка внутренней информации), (2) секреты, зашитые в appsettings.json (используйте User Secrets / переменные окружения / Key Vault), (3) отсутствие атрибутов авторизации ([Authorize]). Плюс небезопасная десериализация (BinaryFormatter и др.), over-posting в model binding (ограничьте через DTO/[Bind]) и CVE зависимостей NuGet. Защита: скрыть подробные ошибки в проде, загружать секреты вне конфигурации, сделать авторизацию явной.