Прошли времена, когда достаточно было пароля посильнее. Современные атаки автоматизированы до такой степени, что ваш сайт могут начать сканировать роботы через 15 минут после запуска. Буквально — робот находит уязвимость раньше, чем вы успеете допить кофе.

1. SQL-инъекция — старая, но всё ещё убивает

В 2026 году SQL-инъекция занимает третье место среди самых распространённых веб-уязвимостей. Не потому что её не умеют закрывать, а потому что разработчики до сих пор лепят запросы через конкатенацию строк.

Типичный пример: пользователь вводит имя в форму, а в поле спрятан символ кавычки. Сервер подставляет это в SQL-запрос без экранирования — и злоумышленник получает доступ ко всей базе данных.

Что делать: Использовать параметризованные запросы (prepared statements). В Node.js это db.prepare('SELECT * FROM users WHERE name = ?').get(name). Одно изменение в запросе — и ваш сайт перестаёт быть лёгкой целью.

2. XSS — ваш сайт как оружие

Межсайтовый скриптинг (XSS) позволяет атакующему встроить свой JavaScript-код на вашу страницу. Посетители заходят на якобы безопасный сайт, а у них крадутся куки, перехватываются данные форм, перенаправляют на фишинговые страницы.

Особенно опасен так называемый «хранимый» XSS — когда вредоносный код сохраняется в базе данных и отдаётся всем посетителям.

Что делать: Экранировать всё, что приходит от пользователя. Использовать Content Security Policy (CSP) — это заголовок, который говорит браузеру, откуда можно загружать скрипты. Настроить его несложно, а эффект — колоссальный.

3. Слабые API-ключи и открытые эндпоинты

Я недавно проверяла один проект и нашла API-ключ от облачного сервиса прямо в публичном репозитории на GitHub. Ключ позволял читать и удалять данные из базы. История закончилась хорошо — мы отозвали ключ за минуту. Но бывает иначе.

В 2026 году автоматические сканирования GitHub находят тысячи ключей ежедневно. Если ваш ключ утек — злоумышленник может использовать ваши ресурсы от вашего имени, а счета будут приходить вам.

Что делать: Хранить ключи только в переменных окружения, никогда в коде. Использовать сервисы вроде GitGuardian или Truffle Hog для автоматического сканирования репозиториев.

4. Устаревшие зависимости — тихая угроза

Ваш проект на Node.js использует 500+ пакетов. Вы обновляете свой код, но обновляете ли вы node_modules? Исследования показывают, что средний проект содержит 16 уязвимых зависимостей, из которых 4 — критические.

Проблема в том, что уязвимость в глубокой зависимости может быть обнаружена через год после установки. К этому моменту ваш сайт уже в продакшене, все работает, и обновление кажется рискованным.

Что делать: Запустить npm audit хотя бы раз в месяц. Использовать Dependabot или Renovate для автоматических pull request с обновлениями. Правило простое: если уязвимость критическая — обновляйте немедленно, если средняя — в рамках ближайшего релиз-цикла.

5. Отсутствие rate limiting — дверь для DDoS

Если ваш API позволяет делать 10 000 запросов в секунду без ограничений — поздравляю, у вас есть персональный DDoS-инструмент для атаки на кого угодно. Атакующий использует ваш сервер как прокси, а получаете проблемы вы.

Реализация проста: достаточно ограничить количество запросов с одного IP-адреса. Современные фреймворки типа Express или Fastify имеют для этого готовые мидлвары.

Что делать: Добавить rate limiting на все публичные эндпоинты. Для авторизованных пользователей — отдельные лимиты повыше, для анонимных — построже. Это не только безопасность, но и защита от случайного наплыва посетителей.

Итого

Безопасность — это не функция, которую добавляют в конце. Это архитектурное решение, которое принимают с первого дня. Хорошая новость: большинство уязвимостей закрываются элементарными практиками — параметризованными запросами, экранированием данных, управлением зависимостями и базовой конфигурацией.

Не нужно быть security-экспертом, чтобы сделать сайт значительно сложнее для атаки. Достаточно знать главные векторы и закрывать их по очереди.