Перейти к содержанию

Canonicalization-safe redaction Auth-токенов

  • Дата: 2026-08-25.
  • Статус: VALIDATED.
  • Тип задачи: security review runtime logging.
  • Компоненты: Fastify, Caddy edge/app, Better Auth.
  • Теги: auth, token, logs, redaction, percent-encoding, fail-path.
  • Связанные решения: 0026.
  • Связанный Skill: отсутствует.

Контекст и границы

Auth parser работает с семантически декодированными query keys, а API/Caddy logs могут сериализовать исходный raw URL. Поэтому строковая защита только буквального token= не эквивалентна защите фактического Auth input.

Запись относится к verification/reset token в известных query/path forms. Она не является общей PII logging policy и не разрешает deploy, чтение секретов или работу с реальными данными.

Что сработало

  • Сопоставлять raw logging representation с тем, что Auth parser фактически декодирует и принимает.
  • Проверять literal, все partial/full percent-encoded комбинации букв query key, path token и token внутри Referer.
  • Повторять сценарий на реальном Caddy fail-path: обычная валидация конфигурации не доказывает redaction process/error log.
  • Сохранять несколько слоёв защиты: narrow edge access-log skip, edge/app URI/Referer filter и API serializer до записи.
  • В live marker scan различать наличие query-key token= и фактическое raw-значение: безопасный token=[REDACTED] является положительным evidence redaction, а не утечкой. Fail-closed критерий строится по уникальному raw marker value плюс ожидаемому числу [REDACTED].
  • Для proxy-level Referrer-Policy проверять handler timing: immediate header покрывает ранние edge responses (401) и Caddy-generated fail-path (502), а deferred header перекрывает legacy upstream response (200). Для общего Product App contract потребовалась пара immediate + deferred directives.

Что не сработало и почему

Regex только для [?&]token= прошла focused tests и Caddy validate/adapt, но пропустила to%6ben=<secret>. URLSearchParams декодировал такой key в token, а raw API/Caddy process log сохранял marker. Синтаксическая валидность и literal-only tests поэтому дали ложное ощущение полноты.

Один обычный edge header не перекрыл strict-origin-when-cross-origin старого STAGE App после reverse_proxy. Один deferred header исправил proxied 200, но отсутствовал на раннем Basic Auth 401 и upstream 502. Только проверка всех трёх response paths обнаружила обе неполные реализации.

Первый STAGE post-check считал любое совпадение token= чувствительным и дал ложный FAIL на уже отредактированном API log. Из-за этого безопасный runtime был временно откачен. Проверка уникальных raw markers отдельно от [REDACTED] устранила неоднозначность до повторного exact-candidate deploy.

Проверки и свидетельства

  • Первый tester/reviewer gate независимо воспроизвёл bypass и выдал REJECTED.
  • После исправления tester подтвердил literal, partial/full encoded key, reset path, Referer, ordinary negative и реальный Caddy 2.10.2 upstream fail-path.
  • Reviewer проверил 32/32 partial/full percent-encoding комбинации имени token и выдал VERIFIED.
  • Отдельный live-header cycle на Caddy 2.10.2 сначала дал REJECTED для deferred-only варианта, затем независимо подтвердил immediate + deferred pair: ровно один no-referrer на proxied 200, Basic Auth 401 и upstream 502, sensitive access-log skip и сохранённую ordinary logging.
  • Полный evidence: task card, session log (session log excluded from published snapshot) и решение 0026.
  • Evidence нового header-cycle: DEV deploy task и live deploy/rollback session (session log excluded from published snapshot).
  • Exact STAGE candidate подтвердил literal/encoded runtime matrix: raw markers API 0/0, [REDACTED] 2, edge raw markers 0/0; отдельный фактический Fastify regression также не содержит raw marker. Evidence: STAGE task card.

Когда применять

  • при добавлении или изменении Auth route, query key, callback/reset URL;
  • при настройке access/process/error logs на proxy или API;
  • при замене Caddy, Auth library, URL parser или request serializer;
  • в predeploy security gate любого Product App environment.
  • при переносе общего edge contract на upstream с собственными security headers.

Когда не применять

  • как замену общей политике PII/secret logging;
  • к Site/Docs referrer policy без отдельного product requirement;
  • как доказательство deployed runtime без live success/fail-path marker search.

Следующее улучшение

После стабилизации Auth contract оценить генерацию negative marker matrix из реестра sensitive routes и parameter names. Новый security Skill пока не создаётся: известен один узкий validated pattern, а общий контракт автоматизации ещё не определён.