Проектирование API с точки зрения безопасности

API стали центральной частью архитектуры современных приложений: они связывают мобильные приложения, веб-интерфейсы, внутренние сервисы и внешних партнёров. Это делает их привлекательной мишенью: достаточно одной ошибки в проверке прав, и злоумышленник получает доступ к тому, к чему не должен.

Именно поэтому вопросы безопасности нужно поднимать не на этапе тестирования, не при первой серьезной нагрузке, а когда API только проектируются: в требованиях, где аналитик закладывает правила доступа, ограничения и ожидаемое поведение в разных сценариях.

И важно понимать, что безопасность API – это не дополнительная опция, которая описывается в приложении к ТЗ. Это часть контракта, по которому системы взаимодействуют друг с другом, и от качества этого контракта во многом зависит, насколько защищён продукт в целом.

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

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

Реальные примеры крупных утечек через API

1. Twitter*: утечка данных 5,4 млн пользователей (2022 год)
Из‑за уязвимости в API злоумышленники смогли сопоставлять email и номера телефонов с аккаунтами, что привело к публикации личных данных миллионов людей на форумах. Это произошло из‑за ошибки в обработке конфиденциальных настроек API, которую исправили лишь после того, как данные стали доступны посторонним.

2. LinkedIn*: массовое извлечение данных через API‑защиты (2021)
Недостатки защиты API позволили злоумышленникам массово скрапить данные профилей пользователей, включая email, профессиональные детали и другие поля, в огромных объёмах, что затем использовалось для создания баз данных и возможных атак социальной инженерии.

3. Facebook*: утечка 533 млн записей пользовательских данных (2021)
API‑слабость в системе позволила злоумышленникам собрать и выложить в открытый доступ огромную базу с личной информацией (телефоны, email, даты рождения и т.п.). Эти данные позже активно использовались для фишинга и мошенничества.

И есть ещё множество других примеров!

Итак, мы видим, что ошибки в безопасности API могут привести к:
◾️утечкам персональных данных
◾️нарушениям законов о защите персональных данных и др.
◾️потере доверия пользователей
◾️прямым финансовым потерям и штрафам
◾️рискам мошенничества, социальной инженерии и фишинга

И в каждом из этих известных кейсов причины были не технические баги в коде, а недостаточная проработка API на этапе проектирования требований.

Так что же делать нам — системным аналитикам? Расскажу в следующем посте.

*запрещенные в РФ соцсети