Як захистити партнерські посилання від конкурентів

Вступ: чому посилання - це гроші

Для афіліата або медіабайера партнерське посилання - це облік прибутку: хто привів гравця, кому платити 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-моніторинг лендінгів: будь-які зміни СТА/скриптів - повідомлення.

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 і дисципліна логування. Додайте до цього юридичну ясність і моніторинг - і конкуренти перестануть «знаходити гроші» у ваших посиланнях.