naeel
8cbbe52316
- ui/routes/auth.js: safeReturn() для returnTo в POST /login и /login-token - src/routes/oidc.js: safeLocal() для oidcReturnTo в /callback
64 lines
5.2 KiB
Markdown
64 lines
5.2 KiB
Markdown
# 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-путь к предсказуемой модели. |