Как защитить партнёрские ссылки от конкурентов

Введение: почему ссылки — это деньги

Для аффилиата или медиабайера партнёрская ссылка — это учёт прибыли: кто привёл игрока, кому платить CPA/RevShare. Любая «утечка» (подмена параметров, перехват клика, кража саб-ID) = потеря денег и репутационные риски у оператора. Ниже — системный план защиты на уровне ссылки, домена, инфраструктуры и процессов.

1) Типовые атаки на партссылки (что именно происходит)

1. Подмена параметров (Param Tampering)

Конкурент меняет `aff_id`, `sub_id`, `campaign` на свои и отправляет трафик через «вашу» витрину.

2. Перехват клика (Click Hijacking/Ad Injection)

Встраивание скрипта/расширения браузера, которое перебивает переход на свою ссылку в последний момент.

3. Cookie stuffing / тайм-банни-хоппинг

Подбрасывают свои куки/пиксели до вашего клика или сразу после, чтобы «украсть» атрибуцию.

4. Бренд-сквоттинг и тайпосквоттинг

Регистрация похожих доменов/ботов и замена ссылок в чатах/сообществах.

5. UTM-стриппинг и саб-ID обнуление

Параметры удаляются на промежуточных редиректах → теряется разрез по источникам/креативам.

6. Скрапинг лендингов и зеркалирование

Копируют страницу вместе с вашими CTA и меняют ссылку на свою.

2) Критические принципы защиты (прежде чем углубляться в технику)

Не храните «голую» партссылку на фронте. Показывайте пользователю короткий собственный URL, а всю «начинку» собирайте на сервере.

Каждый клик — уникальный. У клика должен быть свой ID и подпись.

Верифицируйте события на стороне сервера. S2S-постбеки, а не только клиентские пиксели.

Минимум доверия промежуточным слоям. Чем меньше редиректов третьих сторон, тем лучше.

3) Техники защиты ссылки

3.1. Серверный редиректор (own link shortener)

Что делать:

Делать все внешние переходы через собственный домен, например `go.yoursite.com/XYZ`.
На сервере собирать исходный оффер-URL и параметры и только там выполнять 302/307 редирект.
Плюсы: скрывает «голую» структуру, позволяет логировать, подписывать и валидировать.
Важно: запрещайте кеширование (Cache-Control: no-store), включите HSTS и корректный `Referrer-Policy`.

3.2. Подпись параметров (HMAC)

Зачем: чтобы нельзя было незаметно заменить `aff_id/sub_id`.

Как:

Формируйте строку параметров в каноническом порядке, добавляйте `ts` (timestamp) и `nonce`, считайте `sign = HMAC_SHA256(secret, payload)`.
Перед редиректом сервер убеждается, что `sign` валиден, `ts` не старше N минут, `nonce` не использовался ранее (храните недолго).
Итог: подмена приводит к невалидной подписи — запрос отвергается.

3.3. Короткоживущие токены

Зачем: минимизировать ценность украденной ссылки.

Как: выдавайте токен (`jwt` или opaque) на 5–15 минут, привязанный к IP/UA или к `click_id`. По истечении — 410 Gone.

3.4. Привязка к click_id и серверные постбеки

Что делать:

На первом клике создайте `click_id` в своей БД.
Перед редиректом шлите pre-back (optional) к оператору/сети.
Все подтверждения (reg/KYC/FTD) — только S2S с валидацией `click_id` и сигнатур.

3.5. Шифрование чувствительных полей

Когда нужно: если некоторые партнёры требуют `aff_id` на фронте.

Как: шифруйте `aff_id/sub_id` асимметрично (public key на фронте, private key на бэке), на сервере расшифровывайте и подставляйте.

3.6. Стабильные редиректы и заголовки

Используйте 307 (сохраняет метод) или 302; избегайте «мета-рефрешей».

Добавьте `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, CSP для прелендов — против clickjacking.

`Referrer-Policy: strict-origin-when-cross-origin` снизит утечки параметров.

4) Защита домена и инфраструктуры

4.1. Доменная гигиена

DNSSEC, короткие TTL, резервный NS-провайдер.

Регистрация «ошибочных» вариантов домена (тайпосквоттинг) и автопереадресация на основной.

Мониторинг новых доменов с вашим брендом/ключами.

4.2. Почтовые ссылки

Включите SPF/DKIM/DMARC — чтобы конкуренты не спуфили рассылки «от вашего имени» с подменой ссылок.

4.3. WAF/бот-фильтры

Режьте подозрительные ASN, известные дата-центры, невалидные UA.

Velocity-правила: много кликов с одного IP/UA → капча/блок.

Подпись и проверка `nonce` на уровне WAF (кэш короткоживущих токенов).

5) Защита фронта: преленды и лэндинги

CSP + SRI: запрет сторонних скриптов, проверка целостности.

Integrity-проверка ссылок: все CTA генерируйте из одного централизованного компонента; сравнивайте перед кликом ожидаемый `href` с эталоном.

Антиинъекции: отключите «плавающие» расширения (по возможности), ловите попытки переписать DOM-ссылку (MutationObserver) и логируйте инцидент.

6) Антифрод и атрибуция качества

Device-фингерпринт/Client hints: помогает улавливать перехват клика и замену параметров.

Поведенческие паттерны: подозрительно высокий CTR при еле живом `reg→FTD` — сигнал для разбирательства.

Списки источников: чёрный/белый лист сайтов/аппов/паблишеров; автоматические правила отключения.

Аудит логов: храните события клика/редиректа/верификации подписи минимум 30–90 дней.

7) Право и комплаенс (очень важно)

Никаких методов обхода правил площадок. Мы защищаем свои ссылки, а не «маскируем» запрещённую рекламу.

Корректные дисклеймеры 18+ и Responsible Gaming.

DPA/SLA с сетью/оператором: термины «валидный FTD», правила постбеков, сроки разборов спорных лидов, журнал инцидентов.

Политика по бренду: запрет brand-bidding партнёрам, правила использования логотипов/названий.

8) Мониторинг и алерты

Задержка постбеков >15 минут → алерт и авто-проверка эндпойнтов.

Скачки CR(click→reg, reg→FTD) или всплеск кликов с одного ASN → флаг.

Доля «битых» подписей HMAC > X% → расследование (возможная подмена ссылок).

Diff-мониторинг лэндингов: любые изменения CTA/скриптов — уведомление.

9) Чек-листы

9.1. Быстрый тех-чек перед запуском

Все внешние ссылки через свой редиректор (go-домен)
HMAC подпись + `ts` + `nonce` на каждый клик
Короткоживущий токен (5–15 мин), привязанный к `click_id`
S2S-постбеки reg/KYC/FTD/2nd dep, синхронизированы TZ/валюты
CSP/SRI, `X-Frame-Options: DENY`, HSTS, no-store
WAF/бот-фильтр и velocity-правила
Логи кликов/редиректов/подписей и дашборд аномалий

9.2. Организационный чек

DPA/SLA с оператором/сетью (инциденты, сроки, лог-доступ)
Политика по бренду и запрет brand-bidding у партнёров
План реагирования: кто, что, в какие сроки делает при инциденте
Регулярный аудит доменов/ботов/зеркал

10) Мини-плейбук расследования инцидента

1. Заморозить спорный источник (кап/пауза).

2. Сверить логи: клики ↔ редиректы ↔ подписи ↔ постбеки.

3. Идентифицировать вектор: tampering, hijacking, injection, stuffing.

4. Применить контрмеры: усилить WAF, обновить ключи HMAC/JWT, добавить домены в чёрный список, включить капчу по паттернам.

5. Документировать кейс: отчёт партнёру/сети, обновить плейбук и алерты.

11) 30-60-90 план внедрения защиты

0–30 дней (База)

Запустить собственный редиректор, включить HSTS, CSP, SRI.

Ввести HMAC-подписи + `ts/nonce`, короткие токены, уникальные `click_id`.

Перевести конверсии на S2S и собрать алерты.

31–60 дней (Усиление)

Подключить WAF/бот-фильтр, velocity-правила, ASN-чёрные списки.

Выкатить дашборды: доля невалидных подписей, задержки постбеков, аномалии CR.

Аудит доменов (тайпо), регистрация защитных вариаций.

61–90 дней (Устойчивость и аудит)

Провести стресс-тесты: массовые клики, проба tampering, отключение третьих скриптов.

Формализовать SLA/инцидент-менеджмент с сетью/оператором.

Раз в квартал — ротация ключей HMAC/JWT и ревизия политик.

Защита партнёрских ссылок — это не «скрыть URL любой ценой», а выстроить контур доверия: серверный редирект, криптографическая подпись параметров, короткоживущие токены, S2S-атрибуция, WAF и дисциплина логирования. Добавьте к этому юридическую ясность и мониторинг — и конкуренты перестанут «находить деньги» в ваших ссылках.