Безпека скорочувачів посилань - чого очікувати від вашого провайдера у 2026 році

Скорочувачі посилань займають незвичне місце на карті поверхні атак. За задумом, це непрозорі редиректори: отримувач короткого посилання не може знати, куди воно веде, доки не натисне на нього. Ця непрозорість є основною цінністю продукту. Вона також робить погано захищений скорочувач корисним інструментом для зловживань.

У цьому дописі розглядається реалістична модель загроз для платформ скорочення посилань, а потім пропонується конкретний чекліст безпеки - десять заходів контролю, які серйозний провайдер повинен бути здатний продемонструвати у 2026 році. Там, де Elido впроваджує контроль, я скажу як саме. Там, де ще ні, - я скажу про це також.

Модель загроз#

Чотири категорії зловживань неодноразово з’являються у звітах про інциденти та аудитах безпеки інфраструктури посилань:

Фішинг та розповсюдження шкідливого ПЗ. Скорочене посилання структурно ідентичне незалежно від того, чи вказує воно на легітимну цільову сторінку, чи на форму збору облікових даних. Зловмисники створюють облікові записи, скорочують шкідливі URL-адреси та розповсюджують їх до того, як автоматизоване виявлення зловживань встигне зреагувати. Асиметрія значна: створення сотні коротких посилань займає секунди; очищення після їх розповсюдження потребує тижнів розслідування.

Витік ключів API. Ключі API, які з’являються в клієнтському JavaScript, публічних репозиторіях GitHub або логах збірки, відкривають широкий шлях доступу. Якщо ключ API зберігається у відкритому тексті в базі даних провайдера, один злам бази даних компрометує кожен ключ кожного клієнта. На відміну від паролів, ключі API рідко ротуються - після компрометації вони залишаються скомпрометованими, доки хтось не помітить незвичну активність API.

Штучне завищення аналітики ботами. Кількість кліків на панелі керування скорочувача посилань є непрямим показником ефективності кампанії. Якщо ці цифри включають кожен монітор доступності, бот для попереднього перегляду посилань, сканери та скриптові запити без фільтрації, то цей сигнал стає шумом. Окрім дратівливих цифр на панелі керування, завищена кількість кліків може вплинути на виставлення рахунків у моделях ціноутворення на основі обсягу, а шахрайський трафік кліків може використовуватися для маніпуляцій у системах атрибуції.

Масові зловживання редиректами. Один робочий простір з необмеженим доступом до API може створювати десятки тисяч коротких посилань за хвилину і спрямовувати їх на фішингову інфраструктуру, кінцеві точки посилення DDoS-атак або системи доставки контенту для шкідливого ПЗ. Без обмеження швидкості для кожного робочого простору один скомпрометований обліковий запис може вплинути на доступність для кожного орендаря платформи.

Чекліст безпеки#

1. Сканування URL перед активацією#

Коли користувач надсилає URL-адресу призначення, платформа повинна перевірити її за допомогою баз даних загроз (threat intelligence feeds) до того, як посилання стане активним. Перевірка лише під час створення ігнорує URL-адреси, які є чистими в перший день, але пізніше додаються до блокувальних списків; правильна архітектура також передбачає асинхронне фонове сканування за розкладом.

Сервіс url-scanner від Elido запускає чотири незалежних джерела паралельно для кожної надісланої URL-адреси: Google Safe Browsing v4 (перевірка на MALWARE, SOCIAL_ENGINEERING, UNWANTED_SOFTWARE, POTENTIALLY_HARMFUL_APPLICATION), PhishTank, SURBL та структурну евристику, яка аналізує властивості URL без зовнішніх викликів. Кожне джерело повертає оцінку ризику від 0 до 100; підсумковий результат використовує максимальну оцінку серед усіх джерел - отже, впевненого збігу з будь-яким одним джерелом достатньо, щоб заблокувати посилання. Посилання з оцінкою 80 або вище блокуються негайно; посилання з оцінкою 40–79 ставляться на карантин і додаються в чергу для глибшого асинхронного сканування. Джерела працюють з лімітом часу 200 мс; повільний зовнішній API відключається за таймаутом і фіксується як такий, що працює з обмеженнями, а не блокує процес створення.

Запитайте свого поточного провайдера: які саме джерела перевіряються, що відбувається, коли цільовий URL додається до списку після створення посилання, і чи існує завдання асинхронного повторного сканування.

2. Вебхуки з підписом HMAC та захистом від повторів з прив'язкою до часової мітки#

Вебхуки - це механізм сповіщень між серверами. Провайдер, який надсилає непідписані запити HTTP POST на вашу кінцеву точку, не дає вам можливості перевірити, чи запит надійшов від нього, а не від зловмисника, який дізнався вашу URL-адресу вебхуку. Стандартне рішення - підписувати кожне корисне навантаження за допомогою HMAC-SHA256 від конкатенації мітки часу Unix та сирого тіла запиту.

Часова мітка має таке ж значення, як і підпис. Без неї зловмисник, який перехопив дійсне підписане повідомлення, може відтворювати його нескінченно. З нею ваш приймач може встановити вікно допуску - зазвичай 5 хвилин - і відхиляти будь-яке повідомлення, де now - timestamp перевищує це вікно.

Підпис вебхуку Elido виглядає як v1=HMAC-SHA256(secret, "${unix_timestamp}.${body}") і передається в заголовку X-Webhook-Signature разом з X-Webhook-Timestamp. Формат підпису відповідає угоді, яку використовує Stripe (v1=hex), тому будь-який існуючий код перевірки вебхуків Stripe адаптується з мінімальними змінами. Очікується, що приймачі будуть відхиляти повідомлення, старіші за їхнє налаштоване вікно допуску.

Запитайте свого поточного провайдера: який алгоритм, яка назва заголовка та чи прив'язана мітка часу до підписаного повідомлення, чи надсилається окремо (останнє дозволяє атаки підміни мітки часу).

3. Обмеження швидкості на рівні робочого простору з урахуванням тарифного плану#

Обмеження швидкості лише на рівні IP є недостатнім для запобігання зловживанням через API. Наполегливий зловмисник використовує змінні IP-адреси; основним обмеженням має бути сам робочий простір. Кошики токенів (token buckets) для кожного робочого простору гарантують, що навіть легітимний користувач, який запустить помилковий скрипт автоматизації, не створить безмежне навантаження на API.

Обмеження з урахуванням тарифного плану роблять контроль точним, а не довільним. Безкоштовному робочому простору з десятьма посиланнями та мінімальним трафіком потрібен менший ліміт сплесків (burst allowance), ніж бізнес-клієнту, який автоматизовано створює посилання для рекламних кампаній. Фіксована швидкість, що застосовується рівномірно, або обмежує платних клієнтів, або залишає безкоштовні облікові записи недостатньо контрольованими.

ratelimit.TieredLimiter від Elido підтримує один кошик токенів на робочий простір, розмір якого залежить від тарифного плану (free, paid, business). Тарифний план визначається за допомогою кешованого запиту з TTL - збої визначення призводять до відкату до плану free, щоб інциденти з базою даних не блокували платних клієнтів. Кошики створюються на рівні робочого простору, незалежно від лімітів на рівні IP, тому обидва типи обмежень спрацьовують за потреби. TieredMiddleware встановлено на групі маршрутів /v1/workspaces/{workspace_id}/** і повертає 429 Too Many Requests з заголовком X-RateLimit-Scope: workspace у разі порушення лімітів.

4. Ключі API, хешовані з використанням pepper, а не в текстовому форматі#

Питання не в тому, чи хешувати ключі API, - питання в тому, який алгоритм використовувати та чи додається секрет на стороні сервера (pepper).

Зберігання у відкритому тексті є неприпустимим. Резервна копія бази даних, неправильно налаштований результат запиту або витік доступу до репліки тільки для читання розкриває кожен ключ кожного клієнта. bcrypt кращий, але має відоме обмеження: він обрізає вхідні дані на 72 байтах, що впливає на довгі випадкові токени. Поточною рекомендацією для нових систем є Argon2id.

Pepper додає другий фактор: навіть якщо база даних буде повністю скомпрометована, ключі неможливо зламати офлайн без володіння секретом сервера додатків. Хешований ключ у базі даних марний без pepper на сервері.

Для зберігання ключів API Elido використовує HMAC-SHA256 з використанням pepper на стороні сервера (handler.HashToken). Текстовий токен повертається рівно один раз під час створення і негайно видаляється з пам'яті додатка. Подальші виклики API хешують вхідний токен Bearer і шукають результат за хешем - текстовий варіант ніколи не зберігається і не записується в логи. Пакет password (використовується для захисту посилань паролем, а не для ключів API) використовує Argon2id з 16-байтним випадковим salt, 64 МіБ пам'яті, 2 ітераціями та 4 потоками - з кодуванням PHC, тому параметри зберігаються разом з хешем і можуть оновлюватися для кожного хешу під час міграції.

Запитайте свого поточного провайдера: чи можуть вони підтвердити хешування при зберіганні та уточнити алгоритм? Якщо відповідь: "ми хешуємо паролі, але ключі можуть зберігатися інакше" - це привід для уточнення.

5. Захист посилань паролем#

Не кожне коротке посилання призначене для широкої публіки. Внутрішні посилання, що розповсюджуються всередині компанії, сторінки раннього доступу та підготовлений контент виграють від додаткового рівня захисту, який вимагає від отримувача підтвердження права доступу.

Паролі посилань хешуються перед зберіганням - платформа ніколи не повинна мати можливості відновити текстовий пароль. Процес перевірки під час редиректу порівнює наданий пароль зі збереженим хешем без будь-яких запитів до бази даних, які повертають хеш у незахищений рівень додатка.

Elido хешує паролі посилань за допомогою тієї ж реалізації Argon2id, що і для облікових даних користувачів. Відповідь API для посилання ніколи не містить password_hash; замість цього повертається булеве поле password_set. Отримувач, який переходить за посиланням, захищеним паролем, отримує 401 з password_required: true та токеном виклику; він має надати правильний пароль у наступному запиті. Хеш перевіряється в процесі за допомогою subtle.ConstantTimeCompare для запобігання перебору на основі часу відповіді.

6. Термін дії посилань та ліміт за кількістю кліків#

Постійні короткі посилання - це операційний ризик. Посилання, створене для кампанії, що завершилася два роки тому, все ще може бути ціллю, все ще може розповсюджуватися у фішингових повідомленнях і все ще з'являтися в аналітиці кліків. Контроль терміну дії дозволяє власникам робочих просторів встановлювати обмежений час життя посилання під час його створення.

Ліміти за кількістю кліків додають інше обмеження: посилання деактивується після заданої кількості успішних редиректів. Це корисно для одноразових посилань на завантаження, попереднього перегляду з обмеженим доступом та будь-яких випадків, коли розмір аудиторії відомий заздалегідь.

Обидва засоби контролю є в моделі посилань Elido. Поле expires_at деактивує посилання в певний час; поле max_clicks деактивує його після N успішних редиректів. Обидва параметри перевіряються на рівні редиректу до реєстрації події кліку. Жоден з них не замінює ручне керування посиланнями, але обидва зменшують радіус ураження посиланням, яке розповсюджується поза межами цільової аудиторії.

7. Журнал аудиту, доступний адміністраторам#

Знати, що ключ API був використаний, - це не те саме, що знати, які кінцеві точки викликалися, що було створено або змінено і коли. Журнал аудиту, який фіксує кожну дію зі зміною стану - створення посилання, видалення, зміну налаштувань, запрошення учасників, випуск та відкликання ключів API - дає адміністраторам робочих просторів докази, необхідні для розслідування підозрілої активності після факту події.

Журнал аудиту має підтримувати пошук, фільтрацію за виконавцем та типом дії, а також експорт. Для корпоративних клієнтів з інтеграцією SIEM події аудиту повинні передаватися в зовнішні системи майже в реальному часі.

Емітер аудиту Elido спрацьовує при кожному успішному виклику обробника змін. Події записуються в Postgres з полями (workspace_id, actor_user_id, kind, target_type, target_id, metadata, ip_address, user_agent, timestamp). Адміністратори робочих просторів мають доступ до даних за останні 90 днів через GET /v1/workspaces/{id}/audit-events з фільтрацією за типом та діапазоном дат. Події аудиту також розсилаються через шину вебхуків як конверти audit.event, тому кінцеві точки вебхуків SIEM-типу отримують повний потік аудиту автоматично. Кінцева точка експорту доказів (/v1/workspaces/{id}/evidence) збирає події аудиту за 90 днів у форматі CSV разом з експортом учасників та правил IP для пакетів відповідності вимогам.

8. Списки дозволених/заборонених IP на рівні робочого простору#

Для клієнтів, орієнтованих на API, де весь трафік походить від відомої інфраструктури, список дозволених IP (IP allowlist) є простим другим фактором: якщо запит надходить з дійсним ключем API, але з IP, якого немає у списку дозволених, - відхиляйте його. Це обмежує радіус ураження витоку ключа зловмисником, який також повинен мати доступ до дозволеного діапазону IP - значно вища планка.

IPAllowlistChecker від Elido - це проміжне ПЗ (middleware) для кожного робочого простору з кешуванням TTL. Префікси зберігаються як діапазони CIDR; перевірка - це тест на входження префікса для проаналізованого IP клієнта (нормалізованого через X-Forwarded-For після того, як наш edge встановлює його). Коли список дозволених увімкнений і не є порожнім, будь-який запит з IP, що не входить до налаштованих префіксів, отримує 403 Forbidden незалежно від дійсності облікових даних.

9. Фільтрація ботів на межі (edge)#

Кожен монітор доступності, пошуковий сканер, генератор попереднього перегляду для соцмереж та клієнт для розгортання посилань, який переходить за коротким посиланням, не повинен з'являтися у вашій аналітиці кліків. Окрім проблеми якості даних, нефільтрований трафік ботів може спричиняти спрацювання лімітів швидкості, завищувати рахунки за кліки та приховувати сигнал людського трафіку в каналах атрибуції.

Сервіс редиректу на межі від Elido запускає детектор ботів на основі User-Agent для кожного запиту перед відправкою події кліку. Детектор перевіряє список із близько 50 підрядків у нижньому регістрі, що охоплюють сканери пошукових систем (Googlebot, Bingbot, Yandexbot, Baiduspider), ботів попереднього перегляду для соцмереж (Twitterbot, LinkedInbot, Discordbot, Slackbot, Telegrambot, WhatsApp, Facebot), монітори доступності (UptimeRobot, Pingdom, StatusCake), HTTP-клієнти (curl, wget, python-requests, axios, PostmanRuntime) та порожні User-Agent (які позначаються як боти безумовно - справжні браузери завжди їх надсилають). Запити, що збігаються з ботами, все одно отримують редирект; пригнічується лише відправка події кліку. Лічильник Prometheus відстежує, скільки подій кліків було відфільтровано на один перезапуск процесу.

Система оцінки підозр (internal/suspicion) працює окремо і позначає кліки як підозрілі, не блокуючи їх: відсутній User-Agent, відсутній заголовок Accept-Language та спрацювання вікна лімітів на рівні IP - кожен чинник додає "м'який" сигнал. Два або більше м'яких сигналів позначають клік як підозрілий у наше аналітичне сховище, де запити аналітики можуть його відфільтрувати.

10. SSO / SAML / SCIM для корпоративних клієнтів#

Для організацій, які керують доступом через постачальника ідентифікаційної інформації (IdP), вимога до співробітників підтримувати окремий пароль для скорочувача посилань створює проблему гігієни облікових даних. SSO усуває цю проблему: скорочувач перевіряє сесію за допомогою IdP і ніколи не працює з самим паролем. SCIM автоматизує життєвий цикл створення та видалення облікових записів, тому коли співробітник звільняється з компанії, його доступ анулюється без оформлення заявки вручну.

SSO в Elido побудовано на WorkOS. SsoHandler надає доступ до операцій CRUD для конфігурації тільки для адміністраторів, публічну кінцеву точку виявлення домену (GET /v1/sso/discover?domain=) для процесу входу та кінцеву точку пошуку з'єднання для зворотного виклику OAuth. WorkOS обробляє деталі протоколів SAML/OIDC та надання доступу SCIM; Elido зіставляє отриманий профіль з учасником робочого простору через рівень ідентифікації Kratos.

Що запитати у вашого поточного провайдера#

Якщо ви оцінюєте, чи залишитися з поточним скорочувачем, чи мігрувати на інший, ось питання, які відокремлюють задокументований стан безпеки від маркетингових заяв:

1. Де зберігаються ключі API - у відкритому тексті, bcrypt чи хеш з використанням pepper? Запитуйте алгоритм, а не запевнення.
2. Як підписуються вихідні вебхуки і чи прив'язує підпис мітку часу для запобігання повторному використанню?
3. Які джерела даних про загрози використовує сканування URL і чи є завдання асинхронного повторного сканування для URL, які старіють?
4. Які ліміти швидкості API для кожного робочого простору і чи відрізняються вони залежно від тарифного плану?
5. Чи є журнал аудиту робочого простору, доступний без звернення в службу підтримки, і чи можна його експортувати?
6. Чи зберігаються хеші паролів посилань за допомогою Argon2id або bcrypt, а не MD5 чи SHA-256?
7. Який механізм виявлення ботів на шляху редиректу і скільки окремих підписів ботів є в списку?
8. Чи підтримує платформа списки дозволених IP на рівні робочого простору, а не лише на рівні облікового запису?

Якщо провайдер не може відповісти на питання 1, 2, 3 та 5 письмово протягом одного робочого дня, документація з безпеки ще не існує або недоступна для вас.

Над чим Elido ще працює в плані безпеки#

Чесна комунікація щодо безпеки означає визнання того, що ще не зроблено.

Обмеження швидкості в Elido зараз реалізовано як локальні для процесу кошики токенів (вбудований у Go rate.Limiter). Це правильно працює для розгортань з однією реплікою і забезпечує незалежне застосування для кожного IP та кожного робочого простору. У випадку горизонтального масштабування з декількома репліками кожна репліка підтримує власний стан кошика - це означає, що робочий простір може перевищити свій номінальний ліміт до N разів на N реплік, перш ніж спрацює будь-який окремий лімітер. Рішенням є розподілений лімітер на базі in-memory кеш, який вже в черзі на розробку, але ще не випущений. У коментарі до пакета існуючого лімітера це задокументовано явно.

Немає вбудованого WAF, окрім лімітів швидкості та фільтрації ботів. Посилення DDoS через масовий трафік редиректів частково пом'якшується лімітами швидкості та обробкою вхідних з'єднань у наш edge, але немає брандмауера на рівні додатків, який би перевіряв корисне навантаження редиректів на наявність ознак ін'єкцій або застосовував гео-блокування. Корпоративні клієнти з великим обсягом публічних посилань повинні планувати використання зовнішнього WAF перед рівнем edge.

Завдання повторного сканування url-scanner працює за розкладом для нещодавно створених посилань, але ще не підтримує ретроактивну чергу сканування всього масиву посилань. Посилання, створене шість місяців тому і жодного разу не перескановане, може вказувати на інфраструктуру, яка з того часу була перепрофільована для зловживань. Асинхронне пересканування всього масиву є в планах розробки.

Ротація ключів API виконується вручну - немає автоматизованої політики закінчення терміну дії, яка б змушувала ротувати ключі за розкладом, є лише необов'язкове поле expires_at, що встановлюється під час створення. Організації з вимогами до ротації ключів повинні встановлювати це поле і впроваджувати процес ротації у свою автоматизацію.

Чекліст, орієнтований на GDPR, охоплює вимоги щодо резидентності даних, обрізання IP-адрес та права на видалення, які доповнюють ці засоби контролю безпеки. Деталі щодо тарифних планів та того, які засоби контролю доступні в кожному плані, дивіться на сторінці цін. Політика конфіденційності Elido описує, як обробляються дані про події кліків у повному ланцюжку редиректу.

Схоже у блозі#

• Schrems II та пікселі відстеження: куди вас приведе DPF у 2026 році
• SCIM та SSO для маркетингових інструментів: про що насправді запитує корпоративний IT-відділ
• Резидентність даних у ЄС для маркетингових інструментів: про що насправді запитує ваш DPO
• Досягнення p95 < 15 мс для редиректів із регіон ЄС, US East та Азійсько-Тихоокеанський регіон