# 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, чем гарантия небольшой
утечки).