pd-guard/todo.md

TODO

Утечка ПД в fail-open ветке ProcessResource

src/main/java/ru/pdguard/api/ProcessResource.java:104-109 — если pipeline.process кидает RuntimeException, сервис отвечает 200 {"result": <payload как есть>}.

Если сбой случился на прямом (маскирующем) шаге, наружу уходит необработанный исходный ПД вместо маски — прямая утечка, которую весь сервис существует, чтобы предотвращать.

Почему не 5xx: по правилам НТ (Приложение B ТЗ) 5 подряд невалидных ответов останавливают весь прогон, поэтому 200 был выбран сознательно, чтобы не срывать проверку. Но текущий фолбэк меняет одну проблему (сорванный прогон) на другую (утечка ПД) — само по себе решение не устраняет риск, а сдвигает его.

Пробовал фикс — затирать буквы/цифры в payload перед возвратом (без утечки, но и без осмысленного контента). Отклонён как сомнительный, отменён.

Нужно придумать более осмысленный вариант: что именно возвращать при внутренней ошибке так, чтобы одновременно (а) не утекал ни один символ исходных ПД и (б) ответ не выглядел как случайная порча данных. Возможные направления для обсуждения: частичное маскирование тем, что успело определиться до сбоя; консервативный ответ вида "обработка недоступна" с фиксированным содержимым; пересмотр самой стратегии (может, лучше редкий 5xx, чем гарантия небольшой утечки).