Зміст
Коротко
Швидкий Node.js-бекенд легко вивести в прод із «тихими» дірками: не в бізнес-логіці, а в regex, залежностях, злитті об’єктів і конфігу. Огляд на Dev.to збирає сім типових класів проблем — корисний як чеклист перед релізом.
Що сталося
Автор описує сценарії, коли команди втрачали дані через дрібниці: ReDoS у користувацькому вводі, шкідливий пакет у ланцюжку npm, prototype pollution через Object.assign/lodash.merge, секрети в .env без ротації, NoSQL injection у запитах MongoDB.
Це не zero-day «з новин», а накопичення дрібних помилок у типовому стеку Express/Fastify/Nest.
Чому це важливо
Екосистема Node заохочує швидкість: npm install, copy-paste middleware, деплой. Безпеку часто відкладають, поки не спрацює сканер або інцидент.
Ключові ризики з матеріалу:
| Загроза | Суть | Мінімум захисту |
|---|---|---|
| ReDoS | «Злий» ввід ламає regex, event loop стає | Аудит regex, ліміти довжини вводу, таймаути |
| Supply chain | Скомпрометований пакет у node_modules |
npm audit, lockfile, npm ci, перевірка maintainers |
| Prototype pollution | Підміна __proto__ через merge |
Безпечний merge, Object.create(null), JSON Schema |
| Секрети | Ключі в env без vault | Secret manager, ротація, не логувати env |
| NoSQL injection | Об’єкт замість рядка в запиті | Валідація схеми, параметризація, allowlist полів |
На практиці
- Перед продом — прогін
npm audit/ OSV / Dependabot і фікс критичних CVE у lockfile. - Вхідні дані — Zod/Valibot на межі API; не довіряти
req.bodyу запитах до БД. - Merge — не мержити довільний JSON від клієнта в конфіг/профіль; для deep merge — перевірені бібліотеки з захистом від pollution.
- Regex — уникати вкладених квантифікаторів на користувацьких рядках; за сумніву — бібліотека на кшталт
safe-regexабо відмова від regex. - CI — SAST + secret scanning (gitleaks, GitHub secret scan).
Для невеликих проєктів достатньо дисципліни; для enterprise — ті самі пункти, але формалізовані в policy та review.
Підсумок
Стаття — нагадування: безпека Node — це не лише HTTPS і helmet. ReDoS і pollution болять так само, як SQL injection в інших стеках. Має сенс пройтися чеклистом раз на квартал або при зміні major-залежностей.

