Ниже — компактное, практическое руководство на примере простого REST API $например,сервиссресурсами/api/users,/api/postsиэндпоинтами/api/login,/api/register$. Для каждого класса уязвимостей — как они проявляются в таком API, пример ошибки проектирования, и какие практики/инструменты применять уже на этапе проектирования и тестирования.

Коротко о сценарии API

Авторизация: /api/login возвращает токен $JWTилисессионныйcookie$.Пользовательские сущности: /api/users/{id} $GET/PUT/DELETE$, /api/posts $CRUD$.Клиент — SPA и мобильные клиенты, браузерный фронтенд использует токен/куки.

1) Аутентификация
Что может пойти не так

Неправильная реализация JWT $длинныйсрокжизни,хранениевlocalStorage\to XSS‑кража$.Отсутствие многофакторной аутентификации для чувствительных операций.Плохо защищённые пароли $нетхешированиясдостаточнымиcost-параметрами$.

Практики на этапе проектирования

Выбирать проверенные протоколы: OAuth2 $authorizationcode+PKCEдляSPA$, OpenID Connect, или хорошо продуманная сессия с secure HttpOnly cookies.Хранение паролей: Argon2 / bcrypt / scrypt с адекватными параметрами.JWT: короткий life-time для access token, refresh token с возможностью отзыва; хранить токены в HttpOnly Secure SameSite cookie $еслииспользуетеcookie$.Защита от брутфорса: rate limiting, lockout, CAPTCHAs для регистрации/входа.

Инструменты/тестирование

Unit/integration tests проверки истечения срока токенов, отзыва refresh token.Тесты на брутфорс/повторение — Hydra, OWASP ZAP fuzzer.CI: проверка конфигурации auth $например,наличиеHTTPS$.

2) Авторизация $accesscontrol$ Что может пойти не так

Недостаточные проверки на уровне ресурсов $IDOR—InsecureDirectObjectReference$: пользователь A может GET/DELETE /api/users/42, принадлежащий пользователю B.Применение авторизации только на frontend.

Практики проектирования

Централизованная проверка прав доступа $middleware$ и контроль на уровне бизнес-логики $object-level$.Принцип наименьших привилегий $RBAC/ABAC$. Для сложных правил — хранить политику отдельно $OPA,Casbin$.Проверка входящих идентификаторов: не полагаться на данные клиента $например,userIdизтелазапроса$.

Тестирование

Автотесты на попытки доступа к чужим ресурсам $интеграционныетесты$.Fuzz/DAST: сценарии доступа разными ролями.Ручной pentest + сценарии IDOR $Burp,Postman+Newmanсценарии$.

3) Валидация вводимых данных
Что может пойти не так

Принятие произвольного JSON без проверки схемы → непредсказуемое поведение, уязвимости.Недостаточные проверки загружаемых файлов $тип,размер$.

Практики проектирования

Использовать контракт API: OpenAPI / JSON Schema и валидировать вход на границе $gateway,frameworkmiddleware$.Белый список полей $rejectunknownproperties$, строгие типы, ограничения длины и форматов.Ограничение размеров тела запроса, контроль типов $Content-Type$, проверка загружаемых файлов $mime+инспекциясодержимого$.

Инструменты/тестирование

Middleware в runtime: express-openapi-validator, Ajv $JSONSchema$, marshmallow $Python$.Автотесты, генерируемые по OpenAPI $schemathesis—фреймворкдляFuzzтестированияOpenAPI$.Существительные unit/integration tests и property-based tests $Hypothesis/QuickCheck$.

4) SQL/NoSQL-инъекции
Что может пойти не так

Конкатенация строк при формировании SQL (например, "... WHERE id = " + req.query.id).В NoSQL $MongoDB$ — передача объекта запроса с операторами ($gt, $where) от клиента и выполнение его напрямую.

Практики проектирования

Использовать параметризованные запросы / подготовленные выражения / ORM с параметрами.Для NoSQL: запрещать передачу операторов в пользовательских полях; использовать строгую сериализацию/сборку запросов $неподставлятьсырыеJSONвзапрос$.Принцип минимальных разрешений DB‑аккаунта $тольконужныетаблицы/операции$.

Инструменты/тестирование

SAST: FindSecBugs $Java$, Bandit $Python$, Semgrep — правила на поиск небезопасных конкатенаций.DAST/fuzz: OWASP ZAP, SQLmap $дляSQL$, NoSQLMap.Код‑ревью чеклисты и CI‑правила, блокирующие использование небезопасных API.

5) XSS $вконтекстеAPI$ Что может пойти не так

API возвращает данные, которые фронтенд встраивает в DOM без экранирования $например,комментарийс<script>$.Отправка HTML в полях, которое позже рендерится в браузере.

Практики проектирования

API должен указывать, что данные — это данные, а рендеринг и экранирование выполняются на клиенте. Но безопаснее — фильтровать/валидировать вход $еслиHTMLнеразрешен$.На клиенте — всегда использовать контекстное экранирование при вставке в HTML $неinnerHTMLбезсанкционированногошаблонизатора$.CSP $ContentSecurityPolicy$ на фронтенд и заголовки безопасности $X-Content-Type-Options,X-Frame-Optionsит.д.$.

Инструменты/тестирование

DAST: OWASP ZAP, Burp для проверки XSS.Тесты на отражённый/хранимый XSS: автоматические сценарии с payload’ами.SCA для фронтенда и проверка шаблонов рендеринга.

6) CSRF
Что может пойти не так

Cookie‑базированная аутентификация без CSRF‑защиты позволит атакующему выполнить нежелательные действия от имени пользователя $например,POST/api/posts$.

Практики проектирования

Для cookie auth: использовать CSRF‑токены $synchronizertokenpattern$ или double submit cookie.Использовать SameSite=Lax/Strict для куки, а для SPA — предпочтительнее хранить access token в HttpOnly cookie + CSRF token.Для API, который требует Authorization header $Bearer$, CSRF менее актуален — т.к. злоумышленник не может прочитать/поставить заголовок из чужого сайта.

Инструменты/тестирование

Проверки наличия и валидации CSRF токенов в тестах.DAST инструменты умеют эмулировать CSRF‑атаки.

7) Утечки логов и секретов
Что может пойти не так

В логах попадают пароли, токены, PII $личныеданные$ — журналы сохраняются долго, могут быть отправлены в внешние системы.Конфигурация CI/CD содержит секреты в открытом виде, закоммичены в репозиторий.

Практики проектирования

Политика логирования: не логировать пароли, токены, полные персональные данные; использовать redaction/masking.Структурированное логирование $JSON$ + фильтрация чувствительных полей.Управление секретами: Vault $HashiCorpVault$, AWS Secrets Manager, Azure Key Vault; не хранить в репозитории.Ограничение доступа к логам, ротация, ретеншен-правила, шифрование логов в хранилище.

Инструменты/тестирование

Secret scanning в CI: git-secrets, truffleHog, detect-secrets.Линтеры/сканеры конфигурации $кпримеру,checkov$.Инструменты для маскировки логов в runtime $bucker$.Мониторинг/SIEM, alert при аномалиях логов.

Дополнительные практики $общаябезопасностьAPI$

TLS $везде$ — HSTS, сильные cipher suites, проверка сертификата.Защита от DDoS: rate limiting $nginx,Envoy,APIGateway$, WAF.Заголовки безопасности: CSP, X-Frame-Options, Referrer-Policy, Strict-Transport-Security.Контроль CORS: не ставьте Access-Control-Allow-Origin: *; разрешайте конкретные происхождения.Версионирование API и возможность быстрого отзыва старых версий.Мониторинг и аудит $trace,auditlogs$, оповещения о аномалиях.

Инструменты для защиты и тестирования $конкретно$

Проектирование и контракт:
OpenAPI/Swagger, JSON Schema, Prism/mock servers.Contract testing: Dredd, Schemathesis, Postman + Newman.SAST и правила безопасности:
Semgrep $универсальный$, Bandit $Python$, gosec $Go$, FindSecBugs/SpotBugs $Java$, Brakeman $Ruby$.SCA $зависимости$:
Snyk, Dependabot, WhiteSource, OWASP Dependency-Check.DAST / API fuzzing:
OWASP ZAP, Burp Suite, Microsoft RESTler $дляавтоматическойгенерациииfuzzдляRESTAPI$, Schemathesis $OpenAPIfuzzing$.Pentest / динамический анализ:
Burp Suite Professional, OWASP ZAP, SQLmap, NoSQLMap.Политики/авторизация:
Open Policy Agent $OPA$, Casbin.Секреты и конфигурация:
HashiCorp Vault, AWS/Google/Azure Secrets Manager, git-secrets.CI/CD интеграция:
Integrate SAST/SCA/DAST in CI $GitHubActions,GitLabCI$ — блокировать PR при уязвимостях.

Пример чек‑листа безопасности на этапе проектирования

Аутентификация: выбран проверенный протокол; хранятся хэши паролей; токены с коротким TTL.Авторизация: централизованный middleware; object-level checks; тесты RBAC.Валидация: OpenAPI + JSON Schema; reject unknown props; лимиты размеров.Инъекции: parameterized queries; no direct construction of DB queries from raw input.XSS/CSRF: CSP; SameSite и CSRF tokens; frontend всегда экранирует данные.Логирование: маскирование секретов; ретеншен; доступ по RBAC.TLS: все endpoint’ы через HTTPS; HSTS.CI: SAST/SCA/DAST + secret scanning включены.Мониторинг: alert на аномалии $трафик/ошибки$, аудиты доступа.

Рекомендации по workflow тестирования

На этапе PR: запуск SAST + SCA + базовых unit/integration тестов, проверка OpenAPI контракта.Nightly CI: DAST-проход $OWASPZAP$ по развернутому staging, Schemathesis fuzz.Перед релизом: внешний pentest/bug bounty для критичных изменений.Runtime: WAF с блокировками, мониторинг, регулярные ревью логов.

Коротко о приоритетах $чтобыначать$

Внедрить HTTPS и проверку сертификатов.Ввести валидацию по схеме $OpenAPI$ на входе и ответах.Заменить небезопасные SQL/NoSQL запросы на параметризованные/ORM.Ввести rate limiting и централизованную авторизацию.Настроить CI с SAST и SCA; периодически запускать DAST и pentest.

Если хотите, могу:

Составить конкретный security checklist и PR‑шаблон для вашей команды;Сгенерировать пример OpenAPI + схема и показать middleware-валидацию для конкретного языка/фреймворка $Express/Koa,Spring,Django/Flask,FastAPIит.д.$;Подготовить набор тестов Schemathesis/RESTler, которые вы сможете запустить в CI.