Код-ревью веб-приложений: выявляем N+1 запросы и XSS до релиза

Вы запускаете новую фичу, а через час — сломанный продакшен. Причина: забыли обработать null в ответе API. Или N+1 запросов, которые убивают базу. Такие случаи — не единичны. Ручное ревью находит на 40% больше логических ошибок, чем любой автоматический анализатор. Мы проводим код-ревью веб-приложений на React, Vue, Laravel и других стеках, чтобы выявить эти проблемы до того, как они попадут к пользователям. За несколько лет работы мы проверили более 50 проектов, и каждый третий содержал критическую уязвимость, которую не заметил CI.

Какие проблемы мы находим в вашем коде?

Корректность: проверяем обработку крайних случаев, логику валидации, корректность работы с необязательными полями. Безопасность: XSS, SQL-инъекции, отсутствие авторизации на критических эндпоинтах. Производительность: N+1 запросы, тяжёлые вычисления на клиенте, неоптимальные индексы в БД. Читаемость: имена переменных, дублирование кода, монолитные функции. Каждая проблема сопровождается примером кода и конкретной рекомендацией.

Какие ошибки чаще всего встречаются в React/TypeScript?

В React проектах мы часто видим:

• Использование any — ломает всю статическую типизацию.
• Мутация состояния напрямую (push в массив вместо setState).
• useEffect без зависимостей — бесконечный цикл или устаревшие данные.
• Чувствительные данные в URL — пароли, токены.

Вот пример правильного подхода:

// ПЛОХО: any разрушает типизацию const handleData = (data: any) => { ... } // ХОРОШО: явный тип interface UserData { id: number; name: string; email: string; } const handleData = (data: UserData) => { ... } // ПЛОХО: useEffect без зависимостей (бесконечный цикл) useEffect(() => { setData(processData(data)); }); // нет массива зависимостей // ПЛОХО: мутация state напрямую items.push(newItem); setItems(items); // ХОРОШО: setItems(prev => [...prev, newItem]); 

Как избежать N+1 запросов на бэкенде?

На бэкенде чаще всего встречаются:

• Отсутствие валидации входящих данных — доверие клиенту.
• N+1 запросы без eager loading.
• Пропущенная проверка прав — любой может удалить чужой пост.

// ПЛОХО: нет валидации входных данных app.post('/users', async (req, res) => { const user = await db.user.create({ data: req.body }); // доверяем клиенту }); // ХОРОШО: Zod-валидация const createUserSchema = z.object({ email: z.string().email(), name: z.string().min(2).max(100), role: z.enum(['user', 'editor']), // не позволяем задать 'admin' }); // ПЛОХО: N+1 запросы const posts = await db.post.findMany(); for (const post of posts) { post.author = await db.user.findUnique({ where: { id: post.authorId } }); // N запросов } // ХОРОШО: include const posts = await db.post.findMany({ include: { author: true } }); // ПЛОХО: отсутствие проверки прав app.delete('/posts/:id', async (req, res) => { await db.post.delete({ where: { id: req.params.id } }); // любой может удалить чужой пост }); // ХОРОШО: app.delete('/posts/:id', authenticate, async (req, res) => { const post = await db.post.findUnique({ where: { id: req.params.id } }); if (post.authorId !== req.user.id) return res.status(403).json({ error: 'Forbidden' }); await db.post.delete({ where: { id: req.params.id } }); }); 

Пример из практики: уязвимость в авторизации

Недавно на одном проекте (React + Laravel) мы нашли уязвимость в эндпоинте удаления комментария. Проверка прав сравнивала post.author_id с user.id, но не учитывала, что пост мог быть изменён. Эту проблему выявило ручное ревью — автоматические тесты не покрывали такой сценарий. После исправления пропала возможность удалять чужие комментарии. Подобные логические ошибки встречаются в 30% проектов. В этом проекте после ревью мы также обнаружили неэффективный алгоритм поиска — линейный перебор 50 000 записей вместо индекса. Замена на бинарный поиск снизила время ответа с 2 секунд до 10 миллисекунд.

Как мы автоматизируем проверки до ревью?

До ревью мы запускаем статический анализ: линтер, type checking, тесты с покрытием. Это снижает нагрузку на ревьюера и ускоряет процесс.

# GitHub Actions: автоматические проверки до ревью - run: npm run typecheck - run: npm run lint - run: npm test -- --coverage - run: npx audit-ci --high 

Какие типичные ошибки выявляет статический анализ?

• any и небезопасные приведения типов.
• Необработанные undefined и null.
• Игнорирование ошибок в Promise.
• Неправильное использование дженериков.

Статический анализ (например, ESLint с правилами @typescript-eslint) отлавливает до 70% таких проблем до попадания в ревью. Однако логические ошибки и уязвимости, требующие понимания контекста, остаются на совести ревьюера.

Что входит в код-ревью

Преимущества код-ревью в нашей команде

Наши инженеры — разработчики с 10+ летним опытом в коммерческой веб-разработке. Мы ревьюируем проекты на React, Vue, Laravel, Node.js, Python. Работаем строго конфиденциально: подписываем NDA по запросу. Гарантируем, что каждый найденный баг будет сопровождаться рекомендацией по исправлению.

Сравните: автоматический анализатор находит около 60% проблем, а ручное ревью — до 90%. Особенно это заметно для логических ошибок и уязвимостей, где контекст критичен. По данным OWASP, ручной аудит выявляет на 30% больше критических уязвимостей по сравнению с автоматизированным сканированием.

Сроки и как начать

Свяжитесь с нами, чтобы обсудить ваш проект. Мы оценим объём работ и предложим сроки от 2 до 10 дней в зависимости от размера проекта. Закажите код-ревью и получите консультацию уже сегодня.