VasilisaMartin736
New member
Когда я только начинал работать с REST API, я был уверен: главное — чтобы фронтенд получал данные. Первый серьёзный инцидент случился, когда мы выкатили внутренний сервис без аутентификации — достаточно было знать URL. Пользователь дёрнул эндпоинт /users/export, и мы получили утечку персональных данных. С того дня я усвоил: безопасность — не опция, а обязательный этап разработки.
Нажать чтобы Перейти на сайт
Одна из частых ошибок — избыточное доверие к входным данным. Я видел API, который принимал JSON с полем role, и если подставить «admin», сервер честно повышал права. Решение простое: никогда не полагайтесь на клиента. Проверяйте типы, длину, диапазоны и сверяйте права на основе токена или сессии, а не данных из запроса.
Вторая проблема — слабая авторизация на уровне объектов. Мы как-то забыли проверить, что пользователь может редактировать только свои записи. Достаточно было подставить id чужого заказа в PUT-запрос, и он менялся. Это классический IDOR. Чтобы избежать, используйте не прямые идентификаторы, а случайные UUID и всегда проверяйте владельца ресурса в бизнес-логике.
Отдельно стоит сказать про rate limiting и CORS. Один раз наш публичный API стал жертвой скрипта, который перебирал пароли — мы не ограничивали частоту запросов. После внедрения лимитов и ретраев с экспоненциальной задержкой проблема ушла. А при работе с CORS помните: нельзя отдавать Access-Control-Allow-Origin: *, если API работает с авторизационными данными. Лучше белый список доменов.
Узнать подробнее →
Не менее важен мониторинг и логирование. Мы долго не могли понять, откуда идут атаки, потому что логировали всё подряд — включая пароли и токены. Пришлось переписывать логи: убрать чувствительные данные, добавить идентификатор запроса, а важные события (смена пароля, вход с нового устройства) отправлять в отдельную систему алертов. Иначе даже успешную атаку не видно.
Итог: безопасность API — это культурный сдвиг в команде. Внедрите автоматические проверки зависимостей, пишите тесты на негативные сценарии, проводите код-ревью с прицелом на уязвимости. Я перестал доверять любому входящему запросу и теперь всегда задаю себе вопрос: «А что если это злоумышленник?» А вы — какие из этих ошибок встречали на своих проектах и как закрывали дыры?
По теме советую почитать: Как я автоматизировал продажи в малом бизнесе: инструменты
Нажать чтобы Перейти на сайтОдна из частых ошибок — избыточное доверие к входным данным. Я видел API, который принимал JSON с полем role, и если подставить «admin», сервер честно повышал права. Решение простое: никогда не полагайтесь на клиента. Проверяйте типы, длину, диапазоны и сверяйте права на основе токена или сессии, а не данных из запроса.
Вторая проблема — слабая авторизация на уровне объектов. Мы как-то забыли проверить, что пользователь может редактировать только свои записи. Достаточно было подставить id чужого заказа в PUT-запрос, и он менялся. Это классический IDOR. Чтобы избежать, используйте не прямые идентификаторы, а случайные UUID и всегда проверяйте владельца ресурса в бизнес-логике.
Отдельно стоит сказать про rate limiting и CORS. Один раз наш публичный API стал жертвой скрипта, который перебирал пароли — мы не ограничивали частоту запросов. После внедрения лимитов и ретраев с экспоненциальной задержкой проблема ушла. А при работе с CORS помните: нельзя отдавать Access-Control-Allow-Origin: *, если API работает с авторизационными данными. Лучше белый список доменов.
Узнать подробнее →Не менее важен мониторинг и логирование. Мы долго не могли понять, откуда идут атаки, потому что логировали всё подряд — включая пароли и токены. Пришлось переписывать логи: убрать чувствительные данные, добавить идентификатор запроса, а важные события (смена пароля, вход с нового устройства) отправлять в отдельную систему алертов. Иначе даже успешную атаку не видно.
Итог: безопасность API — это культурный сдвиг в команде. Внедрите автоматические проверки зависимостей, пишите тесты на негативные сценарии, проводите код-ревью с прицелом на уязвимости. Я перестал доверять любому входящему запросу и теперь всегда задаю себе вопрос: «А что если это злоумышленник?» А вы — какие из этих ошибок встречали на своих проектах и как закрывали дыры?
По теме советую почитать: Как я автоматизировал продажи в малом бизнесе: инструменты