docs: note the fail-open PD leak risk in ProcessResource

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Максименко Никита Владимирович
2026-09-22 00:29:43 +03:00
co-authored by Claude Sonnet 5
parent 7f8e0d2d2e
commit 0b10994842
+26
View File
@@ -0,0 +1,26 @@
# 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, чем гарантия небольшой
утечки).