Files
backend/.ai/conventions/security-auth.md
T
ksv741 016782657a
Backend security / security (pull_request) Successful in 7s
Backend verify / verify (pull_request) Successful in 2m3s
Conventional commits / commits (pull_request) Successful in 24s
Backend security / security (push) Successful in 7s
Backend verify / verify (push) Successful in 2m10s
docs: simplify conventions layout
2026-09-15 05:58:33 +03:00

4.2 KiB
Raw Blame History

Security и auth

Читай при изменении session/token/cookie/guard, account access, encryption или sensitive logging; обычный data query без этой границы не требует всего документа.

Выбор владельца

Identity/session — AuthService + strategy/guard; cookie transport — AuthController; account access/connection generation — TbankAccessService; token crypto — TbankTokenService/TbankCrypto. Расширяй существующую boundary, не добавляй второй JWT middleware, decrypt helper или refresh coordinator.

Authentication и ADR 006/009 задают session semantics. Access хранится только в памяти frontend; refresh передаётся httpOnly cookie. Source code конфигурации cookie — AuthController; изменение flags/path требует проверки browser/HTTP поведения, не только TypeScript.

Refresh rotation атомарна: один победитель, проигравший/superseded token получает 401, но сам по себе не отзывает session победителя. Не вводи replay history/grace или иной security contract без текущей задачи. Logout идемпотентен; in-memory frontend session/cache очищается и при network failure.

Trust boundaries

Frontend не является security boundary. DTO runtime validation выполняется server-side; whitelist не заменяет access checks. Environment/secret inputs проверяет existing config owner; реальные credentials не попадают в fixtures.

Verified JWT не доказывает доступ к accountId из URL. Используй user.sub и existing account access policy; не доверяй userId/token из клиента как authority. Cross-user, invalid/expired/superseded token и concurrent requests — обязательные cases для соответствующего изменения.

T-Bank credentials остаются server-side и хранятся encrypted. Используй existing AES-256-GCM boundary с validated 32-byte key; не печатай plaintext, шифротекст, cookie, Authorization или connection generation в logs/errors/API. Connection source определяет cache invalidation при замене/deletion и ограничение key rotation.

Не передавай Prisma User/Session целиком наружу; выбирай public DTO. Пароль обрабатывает существующий bcrypt flow. Не копируй требования о нормализации или длине из tutorial: сверяй runtime DTO, tests и feature source.

Предпочитай Prisma query API. Raw SQL допускается только по конкретной нужде с параметризованными значениями; не конкатенируй untrusted input и не передавай его в queryRawUnsafe/executeRawUnsafe. Dynamic identifiers выбирай из закрытого server-owned набора. Проверка user ownership сохраняется и в SQL.

Безопасный путь и проверка

При неясной ownership/crypto/session семантике прочитай exact source до edits. Добавляй проверку на ответственной границе; не скрывай проблему общим catch, фиктивным success или log. Logger allowlist/redaction не делает произвольный message безопасным.

Targeted auth/access/crypto/logging tests + Testing. Cookie/guard/HTTP changes требуют configured HTTP proof; frontend Bearer/retry проверяется MSW. Schema parity не доказывает отсутствие утечки secret.