До 30% всей экономики в мобильных проектах с открытым API подвергается фроду в первые две недели после релиза: хакеры используют простые снифферы трафика для подмены значений Bonus Points. Если ваш клиент Unity отправляет запрос UpdateUserInternalData напрямую, вы фактически дарите валюту любому пользователю с установленным Charles Proxy или Fiddler.
Уязвимость клиентских запросов в PlayFab SDK
Основная ошибка новичков — использование Client-side API для начисления очков. В этом сценарии Unity-клиент говорит серверу: «Я выполнил квест, добавь мне 500 очков». Злоумышленнику достаточно перехватить один HTTPS-запрос и изменить значение 500 на 500 000. Даже при наличии SSL-сертификатов, обход защиты на Android через установку пользовательского сертификата занимает менее 10 минут.
Кейс: в одном из гиперказуальных проектов с оборотом $10k/мес из-за открытого API за неделю «нарисовали» 15 миллионов бонусных очков, что полностью обнулило ценность внутриигрового магазина. Экспертный вывод: любые операции, влияющие на баланс, должны быть вынесены из клиентской части. Клиент может только уведомлять о событии, но не определять награду.
Верификация через CloudScript и Azure Functions
Единственный надежный способ защиты — перенос логики на сервер через CloudScript (JavaScript) или Azure Functions (C#). Вместо прямого обновления баланса, клиент вызывает функцию, передавая ей только ID события или минимальный набор параметров. Сервер самостоятельно проверяет, мог ли игрок получить эти очки: например, прошел ли он уровень X за время Y. Это снижает вероятность успешного фрода до <1%.
Сравнение: стандартный Client API работает с задержкой 100-300 мс, CloudScript добавляет еще 200-500 мс на выполнение скрипта. Однако эта задержка незаметна при правильной интеграция PlayFab SDK с Unity: оптимизация запросов к API для обновления баланса Bonus Points в реальном времени позволяет скрыть лаг за анимацией получения награды.
Методы защиты от повторных запросов (Replay Attacks)
Даже при использовании CloudScript возникает риск Replay Attack: хакер записывает корректный запрос на получение награды и отправляет его серверу 1000 раз. Для борьбы с этим внедряется система уникальных Transaction ID или Timestamp-верификация. Если сервер видит два запроса с одинаковым ID или разницей во времени менее 1 секунды для одного и того же события, второй запрос отклоняется с ошибкой 403.
На практике внедрение такой проверки увеличивает объем передаваемых данных на 0.1-0.5 КБ на запрос, что ничтожно мало по сравнению с риском гиперинфляции валюты. Экспертный вывод: без проверки уникальности события любая серверная функция превращается в «дыру» для накрутки через простые циклы в Python-скриптах.
Валидация игровых метрик и анти-чит фильтры
Продвинутый уровень защиты — проверка «физической возможности» достижения результата. Если игрок заявляет о прохождении уровня за 2 секунды, хотя минимально возможный рекорд — 40 секунд, сервер должен не просто отклонить запрос, а пометить аккаунт флагом «Suspected Cheat». В PlayFab это реализуется через сегментацию: игроки с аномальными всплесками Bonus Points попадают в отдельный сегмент для ручного бана или ограничения вывода наград.
Пример: в RPG-проекте была внедрена проверка соотношения «количество убитых монстров / время сессии». При отклонении более чем на 300% от среднего значения по когорте, начисление очков блокировалось. Это позволило отсечь 95% ботов-фармеров. Экспертный вывод: доверяйте данным, но проверяйте их на соответствие здравому смыслу и статистике вашей аудитории.
Вывод
Забудьте о Client-side API для управления Bonus Points — это путь к краху экономики. Единственный профессиональный стек: Unity → Azure Functions → PlayFab Server API. Начинайте с внедрения серверной валидации событий и обязательной проверки Transaction ID. Избегайте простых JS-скриптов в CloudScript для сложных расчетов — переходите на C# в Azure Functions, чтобы иметь полный контроль над бизнес-логикой и безопасностью.