Приватность по умолчанию на уровне HTTP: заголовки, сокращающие поверхность трекинга
Два заголовка ответа — Permissions-Policy и Referrer-Policy — определяют, сколько ваши страницы отдают ad-tech и третьим сторонам. Задайте их один раз, и поверхность слежки закроется по умолчанию.
Большая часть работы с приватностью происходит в JavaScript — логика согласия, гейтинг тегов, ротация идентификаторов. Но браузер даёт вам два заголовка HTTP-ответа, которые закрывают поверхность слежки ещё до запуска хотя бы одного скрипта, и большинство сайтов не задают ни одного. Permissions-Policy и Referrer-Policy — это privacy by design в самом буквальном виде: конфигурация, а не код.
Сейчас они важнее, чем год назад. После того как в октябре 2025 года Google свернул большинство API Privacy Sandbox, остаточные ad-tech-директивы, которые эти API ввели, всё ещё зашиты в Chrome — и сайт теперь может явно их отключить, а не ждать их удаления.
Permissions-Policy: запретите функции, которыми вы никогда не пользуетесь
Permissions-Policy управляет тем, какие функции браузера могут использовать документ и его встроенные фреймы. Это тот же механизм, что регулирует camera, geolocation и microphone — но он также регулирует близкие к трекингу API, к которым тянется ad-tech.
Список разрешений по умолчанию для большинства из них либеральный. browsing-topics, директива, управляющая Topics API, по умолчанию имеет значение * — любой origin на странице, включая сторонние фреймы, может её вызвать, если вы не указали иное. Отключить её — одна строка:
Permissions-Policy: browsing-topics=()
Пустой список разрешений () запрещает функцию всем, включая ваш собственный origin. Вы можете заблокировать весь набор API рекламных интересов и измерений одним заголовком:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()
Любой скрипт — собственный или встроенный — который вызывает document.browsingTopics() или отправляет заголовок запроса Sec-Browsing-Topics, теперь падает с NotAllowedError. Вы не полагаетесь на добросовестность третьих сторон; вы убираете саму возможность на уровне платформы.
Эти директивы объявлены устаревшими вместе с Privacy Sandbox, поэтому некоторые исчезнут из Chrome в ближайших релизах. Установка их в () безвредна после их удаления и защищает до тех пор.
Referrer-Policy: перестаньте утекать свои URL
Каждая навигация и каждый запрос подресурса может нести заголовок Referer, называющий страницу, с которой пришёл пользователь. Полные URL утекают строки запроса, закодированные в пути идентификаторы, поисковые термины и внутреннюю структуру страниц к каждой третьей стороне, которую вы загружаете — поставщикам аналитики, шрифтам, CDN, рекламным пикселям.
Современные браузеры по умолчанию используют strict-origin-when-cross-origin, что уже является разумной планкой:
Referrer-Policy: strict-origin-when-cross-origin
При этой политике браузер отправляет полный URL только в same-origin-запросах, отправляет только origin в защищённых cross-origin-запросах и ничего не отправляет при понижении с HTTPS до HTTP. Так https://app.example/orders/4815?token=abc доходит до третьей стороны как https://app.example/ — origin, без пути, без запроса.
Это значение стало значением по умолчанию в спецификации в ноябре 2020 года, но заголовок всё равно стоит задавать явно. Неправильно настроенный upstream, старое значение по умолчанию во фреймворке или тег <meta> referrer могут его переопределить, а явный заголовок поддаётся аудиту. Если вы не встраиваете ничего чувствительного в URL и хотите быть строже, strict-origin отбрасывает путь и в same-origin-запросах.
Почему это сочетается с аналитикой без cookie
Эти заголовки и privacy-first-трекер решают одну и ту же задачу с двух сторон. Трекер контролирует, что собирает ваша аналитика; заголовки контролируют, до чего могут добраться все остальные на странице.
Трекер без cookie, который выводит идентичность из одностороннего суточного хеша — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — никогда не нуждается в полном URL реферера или в Topics API для своей работы. Он читает document.referrer лишь для атрибуции источника визита, и origin для этого достаточно. Поэтому ужесточение Referrer-Policy ничего не стоит вашей аналитике, при этом закрывая утечку для каждого другого запроса на странице.
То же согласование действует и для производительности. Заголовки стоят ноль байтов JavaScript и ноль времени основного потока; они вычисляются браузером до парсинга. Вы получаете измеримое улучшение приватности без влияния на Largest Contentful Paint или Interaction to Next Paint — противоположный компромисс относительно платформы управления согласием, которая добавляет вес скриптов ради управления разрешениями, которые заголовок мог бы запретить напрямую.
Раздавайте их на edge
Задайте оба заголовка на своём edge- или origin-сервере, чтобы их нёс каждый ответ, включая статические ресурсы и HTML:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin
В Cloudflare добавьте их в Transform Rule или Worker; в Next.js — в конфигурацию headers(); в любом обратном прокси — одна строка add_header. Риска при раскатке нет: вы запрещаете возможности, которыми не пользуетесь, и урезаете данные, которые никогда не хотели отправлять.
Privacy by design обычно подают как архитектурное решение. На уровне HTTP это две строки конфигурации, и они открыты по умолчанию, пока вы их не закроете.
Comments
Loading comments…