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

Сокращатели ссылок занимают необычное место на карте векторов атак. По своей сути они являются непрозрачными редиректорами: получатель сокращенной ссылки не может понять, куда она ведет, пока не кликнет по ней. Эта непрозрачность - основная ценность продукта. Но именно она делает плохо защищенный сокращатель полезным инструментом для злоупотреблений.

В этом посте мы разберем реалистичную модель угроз для платформ сокращения ссылок, а затем пройдемся по конкретному чек-листу безопасности - десяти мерам контроля, которые серьезный провайдер должен уметь продемонстрировать в 2026 году. Там, где Elido внедрил меру контроля, я объясню, как именно. Там, где это еще не сделано, я честно об этом скажу.

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

В отчетах об инцидентах и аудитах безопасности инфраструктуры ссылок неоднократно встречаются четыре категории злоупотреблений:

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

Утечка API-ключей. API-ключи, попадающие в клиентский JavaScript, публичные репозитории GitHub или логи сборки, открывают широкий путь доступа. Если API-ключ хранится в базе данных провайдера в открытом виде, единственная утечка БД раскрывает ключи каждого клиента. В отличие от паролей, API-ключи редко подвергаются ротации - однажды скомпрометированные, они остаются таковыми, пока кто-то не заметит подозрительную активность.

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

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

Чек-лист безопасности#

1. Сканирование URL перед активацией#

Когда пользователь отправляет целевой URL, платформа должна проверить его по базам данных угроз перед тем, как ссылка станет активной. Проверка только в момент создания пропускает 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 timestamp и необработанного тела сообщения.

Компонент временной метки важен так же, как и подпись. Без него злоумышленник, перехвативший валидную подписанную нагрузку, может воспроизводить её бесконечно. С ним ваш приемник может применять окно допуска - обычно 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; ограничивающим фактором должен быть сам воркспейс. Токен-бакеты для каждого воркспейса гарантируют, что даже легитимный пользователь, запустивший неудачный скрипт автоматизации, не создаст неограниченную нагрузку на API.

Лимиты, зависящие от тарифного плана, делают ограничения точными, а не произвольными. Бесплатному воркспейсу с десятью ссылками и минимальным трафиком требуется меньший запас для всплесков, чем бизнес-клиенту, создающему ссылки через пайплайны автоматизации. Единый плоский лимит либо мешает платным клиентам, либо оставляет бесплатные аккаунты без должного контроля.

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

4. API-ключи, хешированные с использованием «перца», а не в открытом виде#

Вопрос не в том, хешировать ли API-ключи, а в том, какой алгоритм используется и подмешивается ли секрет на стороне сервера («перец»).

Хранение в открытом виде недопустимо. Резервная копия базы данных, неверно настроенный результат запроса или утечка доступа к реплике для чтения раскроют все ключи каждого клиента. bcrypt лучше, но имеет известное ограничение: он обрезает входные данные до 72 байт, что критично для длинных случайных токенов. Актуальная рекомендация для новых систем - Argon2id.

«Перец» добавляет второй фактор: даже если база данных будет полностью скомпрометирована, ключи невозможно подобрать офлайн без секрета с сервера приложений. Хешированный ключ в БД бесполезен без «перца» на сервере.

Хранилище API-ключей Elido использует HMAC-SHA256 с серверным «перцем» (handler.HashToken). Токен в открытом виде возвращается ровно один раз при создании и немедленно удаляется из памяти приложения. Последующие вызовы API хешируют входящий токен Bearer и ищут результат по хешу - открытый текст никогда не сохраняется и не логируется. Пакет password (используемый для защиты ссылок паролем, а не для API-ключей) использует Argon2id с 16-байтным случайным солью, 64 МиБ памяти, 2 итерациями и 4 потоками - с PHC-encoded, чтобы параметры хранились вместе с хешем и могли обновляться при миграции.

Спросите вашего текущего провайдера: могут ли они подтвердить хеширование при хранении и назвать алгоритм? Если ответ «мы хешируем пароли, но с ключами может быть иначе» - это повод задуматься.

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 - это простой второй фактор: если запрос приходит с валидным API-ключом, но с IP, не входящего в белый список, - отклонить его. Это ограничивает ущерб от утечки ключа злоумышленнику, которому также потребуется доступ к разрешенному диапазону IP - а это значительно более высокая планка.

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

9. Фильтрация ботов на уровне edge#

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

Сервис 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 для крупных компаний#

Для организаций, управляющих доступом через Identity Provider (IdP), требование к сотрудникам иметь отдельный пароль для сокращателя ссылок создает проблемы с гигиеной учетных данных. SSO устраняет эту проблему: сокращатель проверяет сессию через IdP и никогда не касается самого пароля. SCIM автоматизирует жизненный цикл подготовки и удаления учетных записей: когда сотрудник покидает компанию, его доступ отзывается автоматически без создания заявок.

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

О чем спросить вашего текущего провайдера#

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

1. Где хранятся API-ключи - в открытом виде, bcrypt или в виде хеша с «перцем»? Просите назвать алгоритм, а не просто заверения.
2. Как подписываются исходящие вебхуки и привязывается ли к подписи временная метка для защиты от повторов?
3. Какие базы данных угроз используются для сканирования 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 - число реплик) до того, как сработает любой ограничитель. Решение - распределенный лимитер на базе Redis - уже в очереди, но еще не выпущено. Комментарии в коде текущего лимитера явно фиксируют этот момент.

Встроенного WAF, кроме лимитов и фильтрации ботов, нет. Усиление DDoS через массовый трафик редиректов частично смягчается лимитами и обработкой соединений edge-прокси, но нет файрвола на уровне приложения, который проверял бы полезную нагрузку редиректов на наличие инъекций или применял гео-блокировку. Корпоративным клиентам с огромным объемом публичных ссылок следует предусмотреть внешний WAF перед уровнем edge.

Задача повторного сканирования в url-scanner запускается по расписанию для недавно созданных ссылок, но пока не поддерживает ретроспективную очередь сканирования по всему корпусу ссылок. Ссылка, созданная полгода назад и ни разу не проверявшаяся повторно, может указывать на инфраструктуру, которая с тех пор стала вредоносной. Полное асинхронное пересканирование всего корпуса ссылок находится в планах развития.

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

Чек-лист, ориентированный на GDPR, охватывает требования к резидентности данных, усечению IP и праву на удаление, которые дополняют эти меры безопасности. Подробности о тарифных планах и доступных функциях смотрите на странице с ценами. Политика конфиденциальности Elido описывает, как обрабатываются данные событий клика во всей цепочке редиректа.

Похожее в блоге#

• Schrems II и отслеживающие пиксели: где вас оставляет DPF в 2026 году
• SCIM и SSO для маркетинговых инструментов: о чем на самом деле спрашивает корпоративное IT
• Резидентность данных в ЕС для маркетинговых инструментов: о чем на самом деле спрашивает ваш DPO
• Достижение p95 < 15 мс для редиректов в регионе, по всему миру