Может ли частный прокси принимать только ваше приложение?
Объясняет пределы ограничений по имени приложения и User-Agent и отличает владение учётными данными от доказательства конкретного исполняемого файла.
Прямой прокси может требовать учётные данные, ограничивать исходные сети и применять политику назначения. Но эти меры не доказывают, что вызывающий — один конкретный исполняемый файл.
User-Agent или собственный заголовок предоставляет клиент, и его можно скопировать. Поэтому имя приложения в запросе непригодно как единственные ворота к частному прокси.
Используйте управление доступом, которое выражает то, что вы действительно можете проверить: авторизованная учётная запись, разрешённое сетевое расположение и предусмотренные назначения. Защищайте и отзывайте клиентские учётные данные через обычный проект приложения по работе с секретами. Затем проверьте разрешённые и отклонённые запросы относительно предусмотренной границы доступа.
Даже более строгая аутентификация клиента устанавливает лишь владение одобренным ключом или учётными данными. Её не следует описывать как абсолютную гарантию того, что никакая другая программа не сможет использовать эти учётные данные.
Если требование состоит в обеспечении целостности управляемых устройств или приложений, обозначьте его как дополнительное системное требование. Не обещайте этого правилом заголовка Squid, которое лишь распознаёт строку, выбранную самим вызывающим.