ipwhitelist-app/docs/production-audit.md

Production Audit: ipwhitelist-app

Дата ревью: 2026-06-04 Основа: prompt-review.txt

Общее заключение

В production отдавать нельзя без доработок. Код в целом собран аккуратно, но есть критичные риски по доступу к /export, redirect-логике и IAM fallback-пути. Документация частично актуальна, но для DevOps сейчас недостаточно согласована и содержит противоречия между старым и новым описанием аутентификации.

Найденные проблемы

Critical

1. Публичный /export в server.js открыт без авторизации и без сетевого allowlist. Это противоречит безопасной production-модели и делает выдачу whitelist доступной любому, кто достучится до приложения.
2. Логика returnTo/redirect допускает open redirect. Значение берётся из запроса и дальше уходит в res.redirect() без нормализации. Это нужно закрывать через safeReturn() или эквивалентный allowlist локальных путей.

Major

1. IAM fallback работает слишком мягко: при ошибке fetchIamUser() приложение silently переходит на JWT claims. Это может привести к неверному определению компании, роли администратора или активного профиля.
2. Документация не сведена в один актуальный источник. README.md, docs/devops-deploy.md, docs/ТЗ-реализация.md, docs/keycloak-auth-reference.md и docs/iam-integration.md частично дублируют и частично противоречат друг другу.
3. Описание /export в документации и в коде расходится. В одном месте маршрут показан как публичный, в другом — как Bearer-protected. Для DevOps это опасно: можно ошибиться на этапе деплоя.

Minor

1. CSP сейчас рабочий, но ослаблен unsafe-inline для скриптов и стилей. Для текущего inline-heavy UI это ожидаемо, но защита от XSS ограниченная.
2. Есть устаревшие или лишние пояснения вокруг mock-режима и IAM, из-за чего сложно понять, какой путь является production и какой — fallback для тестов.

Понятность DevOps

Оценка: 4/10

Почему так низко:

• есть хороший стартовый deploy guide, но он смешан с историческими и legacy-документами;
• не все переменные окружения и режимы описаны в одном месте;
• есть расхождения по IAM, роли администратора, multi-company и /export.

Чистота кода

Оценка: 6/10

Плюсы:

• логика разделена на слои: auth, API, UI, queries, validators;
• есть нормализация CIDR, защита от дубликатов и пересечений, soft delete, аудит;
• middleware и роутизация читаются достаточно последовательно.

Минусы:

• fallback-пути слишком терпимые и могут скрыть проблемы интеграции;
• redirect-логика требует жёсткой нормализации;
• часть безопасности опирается на inline-механики и не доведена до строгого production-профиля.

Что исправить перед продом

1. Закрыть /export по умолчанию и включать его только через явную production-политику доступа.
2. Нормализовать все returnTo/redirect-цели через safeReturn() или аналогичный allowlist.
3. Перевести IAM fallback на fail-closed поведение либо явно документировать, при каких условиях он допустим.
4. Свести документацию в один актуальный production runbook и пометить старые документы как legacy.
5. Добавить тесты на open redirect, IAM-fallback и доступ к /export.

Краткий итог

Код готов к дальнейшей доводке, но до production не дотягивает из-за вопросов безопасности и несогласованной документации. Если нужен рабочий контур для DevOps, сначала надо закрыть доступ к /export, убрать open redirect и привести IAM-путь к предсказуемой модели.