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

#Express #framework #access control #dependency management

Безопасность Express (Node.js) — референс по продакшн-закалке

Референс по продакшн-закалке Express (Node.js): будучи минимальным, защиту вы добавляете сами — заголовки helmet, CVE из npm, валидация ввода, авторизация, ограничение частоты, сессии/CSRF и SSRF. Защитно, без шагов атаки.

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

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

Проще говоря

Проще говоря: Express минималистичен и почти ничего не защищает по умолчанию, поэтому защиту вы добавляете сами — и порядок важен. Сначала P0: заголовки безопасности (helmet) + отключить x-powered-by / мониторинг CVE зависимостей npm + быстрое патчение / секреты из окружения, не поставлять stack traces. Затем P1: валидация ввода и защита от инъекций / авторизация по владельцу. Наконец P2: ограничение частоты и лимиты размера / сессии, cookie, CSRF / SSRF. Проработайте таблицу ниже сверху вниз — и закроете большинство пробелов минимального фреймворка.

Чек-лист закалки по приоритету

Прорабатывайте таблицу сверху вниз. P0 — предпосылка, P1 — самый частый источник инцидентов, P2 — постоянная эксплуатационная гигиена.

P0 ── Предпосылка (сначала)

Заголовки (helmet) + отключить x-powered-by / мониторинг CVE зависимостей npm / секреты из env, без экспозиции stack

P1 ── Главный источник инцидентов

Валидация ввода и защита от инъекций / авторизация по владельцу

P2 ── Эксплуатационная гигиена

Ограничение частоты и лимиты размера / сессии, cookie, CSRF / SSRF

Закаляйте от фундамента вверх: P0 (предпосылка) → P1 (главный источник инцидентов) → P2 (эксплуатационная гигиена).

Приоритет	Контроль	Специфика (Express)
P0	Заголовки безопасности	Уровня helmet: CSP/HSTS/X-Content-Type и т.п. Отключите `x-powered-by`
P0	CVE зависимостей npm	Мониторьте через `npm audit`/osv-scanner; судите по работающей версии, быстро патчите
P0	Секреты и ошибки	Секреты из переменных окружения. Не поставляйте stack traces в продакшн
P1	Валидация ввода	Валидируйте/санитизируйте ввод (тип/диапазон/допустимое). Лимиты размера тела
P1	Инъекции	Привязывайте запросы к БД. Следите за NoSQL операторной инъекцией (`$`). Не передавайте ввод в `eval`
P1	Авторизация	Аутентификация + авторизация по владельцу на каждом маршруте. JWT: проверка подписи, фиксация alg
P2	Ограничение частоты	Лимиты попыток/пропускной способности на входе/API. Сдерживает перебор, злоупотребление, DoS
P2	Сессии/cookie	`secure`/`httpOnly`/`sameSite`. CSRF (cookie-сессии). Продакшн-хранилище сессий
P2	SSRF	Allowlist для серверных запросов + блокировка внутренних IP/метаданных

1. Заголовки безопасности и сокращение экспозиции (P0)

Express по умолчанию не устанавливает заголовки безопасности. Поднимите этот базовый уровень первым.

Используйте middleware уровня helmet, чтобы добавить CSP, HSTS, X-Content-Type-Options, frameguard и др.
Отключите x-powered-by, чтобы сократить экспозицию фреймворка/версии.
Проверьте собственный сайт проверкой заголовков безопасности.

2. Зависимости (npm) и цепочка поставок (P0)

Машинно мониторьте CVE зависимостей через npm audit или osv-scanner, судите по работающей версии и быстро патчите (→ мониторинг CVE зависимостей).
У Node большое дерево зависимостей и риск цепочки поставок (тайпсквоттинг, postinstall-хуки). Проверяйте при установке и держите число зависимостей низким.
Держите Node на поддерживаемой (LTS) версии и не оставляйте EOL-версии.

3. Валидация ввода и инъекции (P1)

Валидируйте/санитизируйте весь ввод (тело, query, params, заголовки). Ставьте лимит размера тела, чтобы сдержать DoS.
SQL: привязывайте через плейсхолдеры; никогда не стройте запросы конкатенацией строк (→ что такое SQL-инъекция).
NoSQL: следите за операторной инъекцией ($) через ввод типа объекта (не передавайте сырые объекты в запросы).
Не передавайте внешний ввод в опасное вычисление вроде eval.

4. Аутентификация и авторизация (P1)

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

нет авторизации — «залогинен = можно»
опора только на порядок/наличие middleware
доверие ID/флагам от клиента как есть
подпись JWT не проверена / разрешён alg:none

Правильно

аутентификация плюс авторизация по владельцу на каждом маршруте
проверка близко к данным (не полагаться на порядок)
повторная проверка на сервере (устойчивость к подмене ID)
проверка подписи JWT + фиксированный alg (отклонять alg:none)

Смотрите что такое IDOR · что такое JWT. Содержимое JWT можно осмотреть самому (декодер JWT).

5. Ограничение частоты и злоупотребление (P2)

Применяйте лимиты попыток/пропускной способности к входу, API и сбросу пароля, чтобы сдержать перебор, злоупотребление и DoS.
Ставьте лимиты размера на тела запросов и загрузки (предотвращает истощение от больших полезных нагрузок).

Ставьте secure/httpOnly/sameSite на cookie сессий.
Для приложений с cookie-сессиями добавьте защиту CSRF (→ что такое CSRF).
Используйте надлежащее хранилище сессий в продакшне (встроенное in-memory хранилище не для продакшна). Пересоздавайте сессию при входе.

7. SSRF и серверные запросы (P2)

Серверная выборка URL, поданных пользователем, должна ограничивать цели allowlist'ом и блокировать доступ к внутренним IP / метаданным облака на этапе подключения (→ что такое SSRF).

8. Обработка ошибок и продакшн-конфиг (P0–P2)

Используйте центральный обработчик ошибок и не поставляйте stack traces наружу.
Запускайте с NODE_ENV=production. За прокси корректно ставьте trust proxy, чтобы схема и IP клиента не определялись неверно.
Надёжно терминируйте TLS/HTTPS.

Проверьте: ваш Express действительно закалён?

Построить — не конец; готово только когда вы проверили. Это защитные самопроверки против вашей же среды.

Заголовки и экспозиция

Подтвердите, что ответы несут заголовки уровня helmet и что x-powered-by исчез — через проверку заголовков.

Ошибки не утекают внутренности

Спровоцируйте ошибку и подтвердите, что наружу не показывается stack trace.

Авторизация держится

В тестовой среде запросите ID ресурса другого пользователя и подтвердите, что в доступе отказано (чтение/обновление/удаление).

Зависимости, ограничение частоты, SSRF

Подтвердите, что npm audit/osv чист, ограничение частоты входа работает, а исходящие запросы не могут достичь внутренних IP.

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

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

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

Хаб: безопасность по фреймворкам · безопасность Next.js (тоже Node)
Практика: мониторинг CVE зависимостей · плейбук реагирования на уязвимости
Глоссарий: что такое IDOR · что такое SSRF · что такое JWT · что такое CSRF
Инструменты: проверка заголовков безопасности · декодер JWT

FAQ

QЧто сделать в первую очередь, чтобы защитить Express?

Три пункта P0: (1) добавьте заголовки безопасности (CSP/HSTS и т.п.) через middleware уровня helmet и отключите x-powered-by; (2) машинно мониторьте CVE зависимостей npm и быстро патчите, судя по работающей версии; (3) читайте секреты из окружения и не поставляйте stack traces в продакшн. Express по умолчанию не защитит это за вас, поэтому их добавление — базовый уровень. Дальше переходите к валидации ввода, авторизации и ограничению частоты.

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

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

QКак настроить аутентификацию и авторизацию?

После того как middleware аутентификации подтвердил вход, всегда пишите авторизацию по владельцу на каждом маршруте — что цель действительно принадлежит пользователю. Не полагайтесь на порядок middleware или само его наличие; проверяйте близко к данным. Если используете JWT, требуйте проверку подписи и фиксируйте alg (отклоняйте alg:none).

QКак управлять уязвимостями зависимостей npm?

Машинно мониторьте известные CVE через npm audit или osv-scanner и быстро патчите, судя по работающей версии. У Node очень большое дерево зависимостей и риск цепочки поставок (тайпсквоттинг, postinstall-хуки), поэтому свежесть зависимостей и проверка при установке решают. Держите Node на поддерживаемой (LTS) версии тоже.

QЧто абсолютный минимум?

(1) заголовки уровня helmet + отключить x-powered-by, (2) валидируйте/санитизируйте весь ввод, (3) авторизация по владельцу, (4) ограничение частоты + лимиты размера тела на входе/API, (5) мониторинг CVE зависимостей npm + быстрое патчение, (6) не поставляйте stack traces в продакшн. Этот минимальный набор закрывает большинство пробелов минимального фреймворка.