Плохая проверка - это разведение кошмаров безопасности в NESTJS
23 июля 2025 г.Проведя годы консультации по проектам Legacy NESTJS, я увидел шаблон, который удерживает меня ночью. Это не сложная бизнес -логика или запутанные зависимости, которые меня больше всего беспокоят - это нечто гораздо проще: проверка.
В отличие от сломанной функции, которая кричит о внимании, плохая проверка тихо накапливается до одного дня, вы смотрите на атаку SQL -инъекции или разбитый сервер, задаваясь вопросом, как это произошло.
Почему ваша первая линия защиты имеет значение больше, чем вы думаете
Представьте себе свое типичное приложение Nestjs. Данные потоки как вода через трубы:
HTTP request → Controller → App Service → Database
Когда вы проверяете в точке входа - прямо на этих запросах DTO - вы по сути установите фильтр на источнике. Пропустите этот шаг, и загрязненные данные протекают по всей вашей системе.
Ошибки проверки, которые я вижу снова и снова
Позвольте мне поделиться тем, что я обнаружил, скрывающийся в производственных кодовых базах.
1. «Это струна, отправьте ее!» Синдром
Это классика:
export class CreateUserDto {
@IsString()
name: string;
@IsString()
description: string;
}
Конечно, вы подтвердили, что это строка. Но как насчет:
- Этот пользователь, который подчиняет имя 10 МБ "?
- Умный хакерский тестирование падает?
- Кто -то встает в сценарий XSS в описании?
2. Дикий запад чисел
Я потерял счет того, сколько раз я видел:
@IsNumber()
quantity: number; // What could go wrong?
Ну, позвольте мне сказать вам, что идет не так:
- Отрицательные количества в корзинах (бесплатные деньги, кто -нибудь?)
- Номера страниц, такие как 999999999, которые доставляют вашу базу данных на колени
- Генерация массива на основе пользовательского ввода, который ест всю вашу оперативную память
3. Строка, которая съела производство
Этот не дает мне спать:
@IsString()
token: string; // Living dangerously
Без проверки контента вы приглашаете:
- Попытки инъекции SQL
- Полезные нагрузки JavaScript, пытаясь получить доступ к переменным вашей среде
- Траверные атаки пути, достигающие и т. Д.
- Xss атаки ждут, чтобы наброситься на ваших пользователей
Как мы сюда попали: краткая история
Классовая революция (2020-го поведения)
Nestjs и класс-владелец изменили игру, но вот улов: большинство разработчиков останавливаются в@IsString()И назовите это днем. Инструменты существуют, но при использовании их правильно требуется знание, которые часто похоронены в документации или изучают с помощью болезненного опыта.
Эра ИИ (2023 г.-презентация)
Теперь у нас есть курсор, Клод и другие помощники искусственного интеллекта. Они изменяют игру, но они не волшебство:
- Они анализируют по одному файлу за раз, пропуская общую картину
- Качество вывода полностью зависит от того, как вы их представляете
Как на самом деле выглядит хорошая проверка
Позвольте мне показать вам разницу, которую может изменить разработка, связанная с AI.
Старый путь:
@IsString()
username: string;
@IsString()
@MaxLength(1000)
content: string;
Более безопасный способ:
// User input fields
@IsString()
@MaxLength(255)
@Matches(/^[a-zA-Z0-9\s\-_]+$/, {
message: 'Only alphanumeric characters, spaces, hyphens, and underscores allowed'
})
@Transform(({ value }) => value?.trim())
username: string;
// Fields that might contain HTML
@IsString()
@MaxLength(10000)
@Transform(({ value }) => sanitizeHtml(value, { allowedTags: [] }))
content: string;
Разница? Второй подход на самом деле думает о том, что может пойти не так.
Истинная стоимость резки углов
Вот какая плохая проверка на самом деле вам стоит:
Безопасность нарушений- Не если, но когда. Инъекция SQL и XSS все еще живы и хорошо в 2025 году.
Коррупция данных- Как только плохие данные входят в вашу базу данных, удачи почистили ее.
Производительность кошмаров- Невинно выглядящий неограниченный запрос? Это бомба с тиканием.
Бизнес -логика неудач- Негативные цены, невозможные даты, расчеты, которые не имеют смысла.
Разработчик страдает- Часы, потраченные на проблемы отладки, которые предотвратили бы надлежащую проверку.
Масштабирование решения
Для крупных устаревших проектов обновление проверки действительно сложно. Вот почему я закончил тем, что построилкласс-владелец-безопасность-энханс, инструмент с AI, который может анализировать и исправлять проверку во всех кодовых базах. Но независимо от того, используете ли вы автоматизацию или нет, принцип остается прежним: относитесь к проверке так же серьезно, как и относиться к своей основной бизнес -логике.
Суть
Вот что я хочу, чтобы вы запомнили:
- Валидация - это ваш ров- он останавливает атаки, прежде чем они смогут нанести ущерб
- Проверка типа - это только начало- Реальная безопасность происходит от проверки контента
- Наследие Кодекс тоже нуждается в любви- Систематические подходы бьют специальные исправления
- ИИ - мощный союзник- Но это нуждается в вашем опыте, чтобы направлять его
- Последовательность - король- Одна слабая звена может поставить под угрозу все
Мы живем в эпоху, когда ИИ может помочь нам написать безопасную проверку за считанные секунды. Инструменты существуют, шаблоны установлены, и знания доступны. Если ваши DTO по -прежнему выглядят так, как будто они с 2019 года, пришло время для обновления.
Оригинал