К основному содержанию
скилл CX Codex

api-audit — скилл для Claude Code: аудит API по OWASP Top 10

Проверяет REST, GraphQL и RPC эндпоинты на дыры из OWASP API Security Top 10 (2023). Нужен, когда перед релизом надо пройтись по контракту API, а не по всему коду.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add briiirussell/cybersecurity-skills --skill api-audit -a claude-code
Открыть на GitHub

Что делает api-audit

Скилл идёт по каждому эндпоинту и ищет конкретные классы ошибок: BOLA, сломанную аутентификацию, mass assignment, отсутствие лимитов, SSRF, дырявый CORS. Сначала он просит составить инвентарь поверхностей — REST-роуты, GraphQL-резолверы, tRPC-процедуры, gRPC-сервисы, Server Actions, вебхуки — и определить модель авторизации и мультитенантности.

Дальше идёт чек-лист по категориям API1–API9. Для BOLA он требует явной проверки владельца в самом запросе, а не отдельным шагом после findById(id), и отдельно смотрит обход связей через .include и eager-loaded relations. Для mass assignment — принимает ли эндпоинт обновления поля вроде role или tenant_id от обычного пользователя. Для лимитов — есть ли ограничение на размер страницы и глубину GraphQL-запроса.

Скилл не заменяет owasp-audit: тот идёт по категориям и по всей кодовой базе, а этот — по поверхности API с паттернами обхода, специфичными для эндпоинтов. Инструменты у него ограничены Read, Grep, Glob, Bash, Write. Ставить стоит, если у вас есть открытый контракт API и вы хотите пройти по нему до того, как это сделает кто-то другой.

Какие задачи решает

  • найти эндпоинты, где объект читается по ID без проверки владельца
  • проверить, не принимает ли update-роут поля вроде role от обычного пользователя
  • убедиться, что на login и password-reset стоит лимит запросов
  • закрыть SSRF в вебхуках и загрузке картинок по URL
  • найти живые старые версии API рядом с новой

Примеры запросов агенту

  • проведи аудит API по OWASP Top 10, начни с инвентаря эндпоинтов
  • найди BOLA в роутах, которые принимают ID объекта
  • проверь GraphQL-резолверы на mass assignment и глубину запроса

Как установить api-audit

1Через Skills CLI (Vercel)

npx skills add briiirussell/cybersecurity-skills --skill api-audit -a claude-code

2Вручную: положить файлы

~/.claude/skills/api-audit/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/api-audit/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора25

web-pentest Скилл ведёт агента по фазам тестирования живого веб-приложения: конфигурация, аутентификация, авторизация, ввод. Нужен, когда есть письменное разрешение на цель. CX Codex +1 545установок secrets-audit Скилл находит утёкшие API-ключи в кодовой базе, истории коммитов и артефактах сборки, а также оценивает схему хранения секретов в проекте. CX Codex +1 456установок threat-modeling Скилл проводит сессию моделирования угроз по STRIDE и деревьям атак для новой фичи или архитектуры, пока кода ещё нет. CX Codex +1 412установок recon Скилл для структурированной разведки авторизованной цели: пассивный сбор, сканирование портов и итоговая карта поверхности атаки. CX Codex +1 405установок mobile-audit Скилл проверяет безопасность мобильных приложений под iOS и Android по стандартам OWASP MASVS и MASTG. Пригодится при аудите кода, настроек хранилища, криптографии и сетевого слоя. CX Codex +1 389установок osint-recon Собирает и сопоставляет данные из открытых источников для анализа цифрового следа и поверхности атаки. Помогает структурировать разведку по доменам, организациям и утечкам. CX Codex +1 386установок prompt-injection Скилл проверяет приложения с ИИ-функциями на промпт-инъекции, обход прав и утечку системного промпта. Пригодится, когда в проект добавили LLM или агента. CX Codex +1 372установок incident-triage Помогает разобрать инцидент безопасности по стандарту NIST SP 800-61: локализовать угрозу, собрать цифровые улики и составить отчёт. CX Codex +1 361установок

Похожие

owasp-security-check sergiodxa Скилл для аудита веб-приложений и REST API: 20 правил по OWASP Top 10, разбор auth, инъекций и утечек данных. Пригодится перед выкатом в прод. CX Codex +1 1 700установок api-and-interface-design addyosmani Помогает проектировать API и границы модулей так, чтобы их было проще использовать и менять. Подходит для REST, GraphQL и публичных интерфейсов. CX Codex +1 62 600установок api-security-review OWASP Скилл прогоняет API по OWASP API Security Top 10 (2023): проверяет аутентификацию, BOLA, SSRF и конфигурацию шлюза. Пригодится перед релизом или при аудите чужого сервиса. CX Codex +1 503установок api-design-principles Seth Hobson Скилл помогает проектировать и проверять REST- и GraphQL API. Пригодится при подготовке спецификации, пересмотре существующего API или согласовании стандартов команды. CX Codex 30 348установок api-recon-and-docs yaklang Скилл помогает исследовать структуру REST, mobile и GraphQL API перед тестированием. Он ищет скрытые эндпоинты, схемы и старые версии интерфейсов. CX Codex +1 3 800установок api-integration-surface-strategy Samuel Berthe Помогает решить, какие поверхности интеграции платформа отдаёт наружу — REST, GraphQL, gRPC, вебхуки, SDK, MCP — и в каком порядке их строить. CX Codex +1 8 000установок

Рядом в теме «Безопасность»

Всё по теме «Безопасность» →

Вопросы о api-audit

Как установить api-audit в Claude?

Выполните npx skills add briiirussell/cybersecurity-skills --skill api-audit -a claude-code. Скилл окажется в ~/.claude/skills/api-audit/SKILL.md.

Что делает api-audit?

Проходит по эндпоинтам API и проверяет их по чек-листу OWASP API Security Top 10 (2023): BOLA, сломанная аутентификация, mass assignment, лимиты, SSRF, CORS и другие категории.

Чем api-audit отличается от owasp-audit?

owasp-audit идёт по категориям и по всей кодовой базе, а api-audit — по контракту API, эндпоинт за эндпоинтом, с паттернами обхода, специфичными для API. Они ссылаются друг на друга там, где категории пересекаются.

Исходный текст

SKILL.md · MIT
---
name: api-audit
description: "Audit REST, GraphQL, and RPC APIs against the OWASP API Security Top 10 (2023). Use when the user mentions 'API security,' 'API audit,' 'BOLA,' 'broken object level authorization,' 'BFLA,' 'function-level authorization,' 'mass assignment,' 'API rate limiting,' 'GraphQL security,' 'REST security,' 'API authentication,' 'API authorization,' 'excessive data exposure,' or needs to review API endpoints for security weaknesses."
allowed-tools: Read, Grep, Glob, Bash, Write
---

# API Audit — REST / GraphQL / RPC Security Review

Perform a systematic security audit of API endpoints against the OWASP API Security Top 10 (2023). Distinct from `owasp-audit` — that's category-driven over a whole codebase, this is surface-driven over the API contract.

Use `owasp-audit` for the codebase as a whole. Use this when you need a focused pass over every endpoint with API-specific bypass patterns. They cross-reference each other where categories overlap.

## Scope the Audit

1. Inventory every API surface — REST routes, GraphQL resolvers, tRPC procedures, gRPC services, Server Actions, webhook handlers, internal RPC
2. Identify auth model — JWT, session cookies, API keys, mTLS, OAuth scopes
3. Identify the tenancy model — single-tenant, multi-tenant, row-level isolation
4. Map sensitive resources — user data, payments, files, admin functions

## Audit Checklist

### API1: Broken Object Level Authorization (BOLA)

The #1 API vulnerability by exploitation frequency. Every endpoint that accepts an object ID needs an explicit ownership check before reading or mutating.

- For each route that takes an ID parameter (`/users/:id`, `/orders/:id`, `/projects/:id`), verify a query like `findFirst({ where: { id, userId } })` runs before any data access — not `findById(id)` then a separate check
- ORM relation traversal: `posts.find(id).user.creditCard` returns another tenant's card if the relation isn't guarded. Audit every `.include`, `.with`, `includes`, eager-loaded relation
- UUIDs are not access control. Sequential IDs make enumeration trivial; UUIDs only slow it down
- Predictable surrogate keys (slugs, public_ids) used as if they were unguessable
- Grep for: `params.id`, `req.params.<id>`, `formData.get("<id>")`, ORM `.findById(` / `.find(` without a `where` clause, GraphQL resolvers that take an `id` arg and call `.findUnique`

### API2: Broken Authentication

- JWT with `alg: none` accepted by the verifier
- JWT secret comparison without `crypto.timingSafeEqual` / equivalent
- Refresh tokens that never rotate or have no revocation list
- Password reset that returns a token in the response body instead of mailing it
- API keys passed in URL query string (logged everywhere — access logs, CDN, proxies)
- Bearer-token compare against `process.env.X` without a presence check — when X is unset, `"Bearer ${undefined}"` is a valid literal
- Grep for: `jwt.verify`, `jsonwebtoken`, `Bearer ${process.env`, `jwt.decode` (without verify), `verify.*alg`

### API3: Broken Object Property Level Authorization (BOPLA / BFLA / Excessive Data Exposure)

- API returns the whole DB row instead of a curated DTO — `res.json(user)` leaks `password_hash`, `stripe_customer_id`, internal flags
- Admin-only fields (role, is_verified, tenant_id) accepted on update endpoints from regular users — **mass assignment**
- GraphQL exposes admin-mutation fields without role-based field-level auth — `mutation UpdateUser($id, $role)` succeeds because the resolver only checks "is the user logged in"
- Grep for: `res.json(<entity>)` without explicit field projection, `Object.assign(record, req.body)`, Mongoose `findByIdAndUpdate(id, req.body)`, Drizzle `.update().set(req.body)`, Sequelize `update(req.body)`, GraphQL resolvers without role checks

### API4: Unrestricted Resource Consumption

- No rate limit on auth endpoints (login, signup, password-reset, SMS-send, email-verify)
- No per-tenant quota on expensive operations (LLM calls, search, file processing, webhook fan-out)
- Page size unbounded — `?limit=10000000` returns 10M rows
- GraphQL query depth not capped — `user { posts { user { posts { ... } } } }` runs forever
- GraphQL query complexity not analyzed — single query that triggers N+1 against 100M rows
- Webhook handlers that re-trigger expensive work without idempotency

### API5: Broken Function Level Authorization (BFLA)

- Auth check on the route but not on the handler — wildcard middleware misses a manually-mounted route
- "Admin-ish" endpoints reachable by changing `POST /api/v1/users/me` to `POST /api/v1/users/<other_id>`
- HTTP verb tampering — `DELETE /admin/users/123` blocked, but `POST /admin/users/123/delete` succeeds
- Conditional auth based on `req.user.role === "admin"` where role is set from a header the client controls
- Sister-route gaps — `PUT /:id` is guarded but `POST /:id/send` writes the same row without the guard. Run sister-route audit (see `owasp-audit`)
- Grep for: every route handler — does it call an auth check explicitly, or rely on something upstream that may or may not match this route's path?

### API6: Unrestricted Access to Sensitive Business Flows

- Endpoint allows automation that bypasses business intent — buying limited stock 1000× per second, reserving every seat in a venue, brute-forcing referral codes
- No CAPTCHA / proof-of-work / device fingerprint on flows that have business-rate constraints (signup, coupon redemption, vote, like)
- Anti-automation checks only on UI, not on the API

### API7: Server-Side Request Forgery (SSRF)

- User-controlled URLs passed to server-side fetch — webhook URLs, image-fetch, SSO callback, PDF render, OG-scrape, link unfurling
- Allow-list checks only the hostname — see `owasp-audit` A10 for the full bypass matrix (9+ patterns including IPv4-mapped IPv6, trailing-dot, cloud metadata, encoded IPs)
- `redirect: "follow"` (default) on fetches with user-controlled URLs lets an attacker bounce through a 302 into the metadata service
- Webhook delivery from your domain to attacker URL — your server's IP is now their proxy

### API8: Security Misconfiguration

- CORS `Access-Control-Allow-Origin: *` combined with `Allow-Credentials: true` (browsers refuse this; servers shouldn't ship it)
- CORS reflection of the `Origin` header without an allow-list — any origin gets allowed
- Verbose error responses leaking stack traces, query strings, internal IDs
- Default OpenAPI / GraphQL introspection exposed in production with full schema
- Missing security headers — see `owasp-audit` A05 for the full baseline values
- HTTP-only flag missing on session cookies

### API9: Improper Inventory Management

- Old API versions (`/v1/`) still live and unpatched alongside `/v2/` — attackers prefer the version with fewer checks
- "Internal" / "staging" endpoints reachable from the internet (deploy-preview URLs, `*-staging.fly.dev` left open)
- Undocumented endpoints — every endpoint should appear in the OpenAPI spec / type-generated client; orphans are an audit signal
- Auto-generated debug endpoints — `/__debug`, `/__db`, `/.well-known/internal/`, framework-default routes
- Grep for: `app.get`, `router.get`, `pages/api/`, `app/api/` directory contents; reconcile against the published API contract

### API10: Unsafe Consumption of APIs

- Your service calls a third-party API and trusts the response without validation — open redirect via `provider.user.profile_url`, XSS via `provider.user.bio` rendered un-escaped
- Server-to-server calls without integrity check (signed JWT, mTLS, HMAC) — anyone who can reach the upstream URL can pretend to be the upstream
- Caching upstream errors as success — a 200 with a JSON error body cached as data

## GraphQL-specific

- Introspection enabled in production (`__schema`, `__type` queries return the full schema)
- Field-level authorization missing — resolvers check "is this query allowed" but not "is this field allowed for this user"
- Query depth + complexity limits absent
- Batching abuse — single HTTP request containing 1000 queries each costing 100ms
- Error messages reveal internal field paths the user shouldn't know exist

## REST-specific

- HTTP verbs not enforced — `GET` accepted on state-changing endpoints (CSRF risk + cache poisoning)
- Content-Type assumptions — handler expects `application/json` but accepts `application/x-www-form-urlencoded` and parses inconsistently
- Path traversal in resource IDs — `/files/../../etc/passwd`

## Webhook handler-specific

- Signature verification missing or bypassable (see `owasp-audit` A02 type-coercion + A04 multi-tenant signature N-way matching)
- Replay attack — no timestamp tolerance or nonce check
- Endpoint exists at a predictable path (`/webhooks/stripe`) without IP allow-list or signature

## Verify Fixes at Runtime

- For BOLA fixes: actually authenticate as user A and request user B's resource; observe 404, not 200
- For mass-assignment fixes: send the request with the extra field set; observe the field is ignored or rejected
- For rate-limit fixes: hit the endpoint at 10× the configured rate; observe 429 not 200
- For CORS fixes: send the request with `Origin: https://evil.com`; observe the browser blocks, not the server

`tsc --noEmit` + build success ≠ fix verified. See also `owasp-audit`'s Verify Fixes at Runtime + Second-Opinion Pass — same playbook applies.

## Report Format

Findings have three dispositions (Fixed / Deferred / Accepted Risk) per the `owasp-audit` convention. For every finding:

```markdown
#### [SEVERITY] APIN: [Title]
**Endpoint:** `METHOD /path/to/endpoint`
**Handler:** `path/to/handler.ts:42`
**CWE:** CWE-XXX

**Description:** [What the vulnerability is]

**Proof of concept:**
```
[curl / request showing the bypass]
```

**Vulnerable Code:**
[snippet]

**Remediation:**
[fixed snippet]

**Verification:** [Concrete adversarial input and the observed response that proves the fix holds]
```

Produce an executive summary grouped by API category, plus an inventory of every endpoint with one of:
- **Audited — clean** (with what was checked)
- **Audited — N findings** (with severities)
- **N/A** (with reason — e.g. health-check endpoint with no auth surface)

## Boundaries

- Only audit APIs the user provides or points you to
- Provide remediation, not exploits — for proof-of-concept, generate the minimum request that demonstrates the issue, not a weaponized payload
- Flag low-confidence findings as "Potential" rather than confirmed
- Never run a BOLA proof-of-concept against a live production endpoint without explicit written authorization — read the code, then propose how to verify in a test environment
- Refuse mass-scanning, credential-stuffing, or any active abuse-flow exploitation

## References

- OWASP API Security Top 10 (2023)
- OWASP Cheat Sheet: REST Security
- OWASP Cheat Sheet: GraphQL Security
- CWE-639 (Authorization Bypass Through User-Controlled Key)
- CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes)

© briiirussell · MIT · briiirussell/cybersecurity-skills

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой