Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

По фреймворкам

Безопасность Express (Node.js) — защита, которую вы добавляете сами

Express — минималистичный фреймворк, который почти ничего не защищает по умолчанию. Поэтому защиту вы добавляете сами — заголовки безопасности, валидацию ввода, авторизацию (не останавливайтесь на аутентификации), ограничение частоты и мониторинг CVE зависимостей (npm). Что и как добавить, защитно, без шагов атаки.

Опубликовано 2026-07-02 Обновлено 2026-07-02 4 мин чтения

Для: всех, кто ведёт API или приложение на Express (Node.js). Здесь нет шагов атаки — только защита, которую вы добавляете к минимальному фреймворку. Полную картину смотрите на хабе безопасности по фреймворкам.

Защита, которую вы добавляете (чего нет в значениях по умолчанию)

Express даёт лишь основу маршрутизации и middleware. Следующего не существует, пока вы это не добавите.

Заголовки безопасности

CSP/HSTS/X-Content-Type и др. Добавляются через middleware уровня helmet.

Валидация ввода

Непроверенный ввод — вход для SQLi/XSS/инъекций.

Авторизация (по владельцу)

Остановитесь на аутентификации — подмена ID раскроет чужие данные (IDOR).

Ограничение частоты

Сдерживает перебор входа, злоупотребление API и DoS.

CVE зависимостей (npm)

Машинно мониторьте и закрывайте известные дыры множества зависимостей.

Секреты и SSRF

Секреты в переменных окружения, не в коде / защита от SSRF при исходящих запросах.

Что добавить самому в Express — фреймворк не защищает это по умолчанию.

Как их закрыть (минимальная пятёрка)

1

Добавьте заголовки безопасности

Используйте middleware уровня helmet, чтобы установить CSP, HSTS, X-Content-Type-Options и др. По умолчанию их нет, поэтому добавьте первыми для базового подъёма. (→ проверка заголовков безопасности)
2

Валидируйте и санитизируйте весь ввод

Валидируйте тело, query, params и заголовки. Никогда не передавайте непроверенные значения в запросы к БД, HTML или команды ОС (защита от инъекций).
3

Пишите авторизацию, а не только аутентификацию

Даже после входа ограничивайте каждую операцию пользователем, которому принадлежит объект. Забудьте об этом — и подмена ID даст оперировать чужими данными (→ что такое IDOR).
4

Ограничение частоты и мониторинг CVE зависимостей

Добавьте ограничение частоты для входа и API, чтобы сдержать перебор и DoS. Машинно мониторьте CVE зависимостей (npm) и быстро закрывайте (→ мониторинг CVE зависимостей). Защищайте исходящие запросы к URL от SSRF (→ что такое SSRF).

Частое (опасное)

  • сырые ответы без заголовков
  • ввод передаётся в БД/HTML без проверки
  • нет авторизации — «залогинен = можно»
  • нет ограничения частоты, CVE зависимостей не закрыты

Правильно

  • заголовки установлены через middleware уровня helmet
  • ввод проверен и санитизирован
  • авторизация по владельцу
  • ограничение частоты + мониторинг CVE зависимостей + быстрое закрытие

Взгляд этого сайта: минимальный фреймворк сочетает свободу с ответственностью

Привлекательность Express — в его лёгкости и свободе, а это значит, что защиту вы тоже проектируете сами. Наш сайт на другом стеке, но основы для Node те же: ставьте заголовки, валидируйте ввод, всегда пишите авторизацию на публичных точках входа и проверяйте зависимости на CVE перед каждым деплоем. У Node особенно велико число зависимостей, поэтому именно свежесть зависимостей решает исход инцидентов. Откажитесь от допущения «фреймворк это защитит» и добавляйте защиту явно — это и есть правильный способ использовать Express.

Читать дальше

FAQ

QExpress — безопасный фреймворк?
A

Express «минималистичен» по замыслу — он даёт основу маршрутизации и middleware и почти не несёт функций безопасности. Поэтому он ни безопасен, ни опасен; защиту добавляете вы. В отличие от Rails или Laravel, которые многое защищают по умолчанию, заголовки, валидацию ввода, авторизацию и ограничение частоты вы должны подключить сами. Больше свободы — больше ответственности.

QНужны ли заголовки безопасности вроде helmet?
A

Да. Express по умолчанию не устанавливает связанные с безопасностью HTTP-заголовки. Используйте middleware уровня helmet, чтобы добавить CSP, HSTS, X-Content-Type-Options и другие, снижая базовые риски вроде кликджекинга и MIME-сниффинга. Это подъём базового уровня одним лишь подключением, поэтому его стоит поставить первым.

QЧто минимально необходимо?
A

(1) Добавьте заголовки безопасности (уровня helmet); (2) валидируйте и санитизируйте весь ввод; (3) не останавливайтесь на входе (аутентификации) — пишите авторизацию по владельцу; (4) ограничивайте частоту входа и API; (5) машинно мониторьте CVE зависимостей (npm) и быстро закрывайте. Эти пять закрывают большинство пробелов минимального фреймворка.