> Мне бы попроще - пострадает ли безопасность, чья и почему.Очень грубо говоря - скорее всего нет.
А точнее, нет такой вещи как "безопасность" вообще. Надо идентифицировать риски, отдавать себе отчёт от чего конкретно надо защищаться (называется "модель угрозы") и на основе этого оценивать, как повлияют на защищённость те или иные меры. Тогда можно будет сказать, пострадет ли безопасность.
>> Вообще, оно вам зачем?
> Пытаюсь создать аналогичный радиосайт. Но дело в том, что разработчик движка
> радиосайта прямо предупреждает, что он не гарантирует отсутствие уязвимостей, через который
> он может быть взломан, и рекомендует иметь это в виду.
Если вы у себя собираетесь движок разворачивать, то у вас есть влияние на веб сайт.
Вам придётся залезть в код, найти где и как как он определят текст, который надо показывать в качестве IP клиента, и дополнить его парсингом хедера X-Forwarded-For. Или писать "Your IP hidden".
> Вот я и пытаюсь "иметь это в виду", защитив его промежуточным реверсным
> прокси.
Сам факт наличия промежуточного прокси защиты добавляет мало. Если он просто транслирует всё как есть, то он пропустит "атаку" как любой другой запрос.
Обратным прокси можно достичь нескольких полезных вещей.
Например, терминировать TLS сессии, а именно публиковать HTTPS даже если апстрим умеет только HTTP.
Или разрешать доступ в определённому пути в URL, вместо корня сайта.
Или фильтровать клиентов по IP.
Или ограничивать интенсивность траффика от конкретных клиентов.
Иногда это даёт необходмую защиту. Иногда нет, зависит от сайта и модели угрозы.
Чтобы защитить дырявый движок обратным прокси, по меньщей мере надо конкретно знать, какие дырки закрывать и как выглядит атака на каждую из них. Неблагодарное занятие.
