本文へ移動
cccskills
無料GitHub で公開

api-security

Guideline for designing, implementing, and verifying secure APIs following OWASP API Security Top 10 (2023) best practices. Use when the user wants to: (1) review API code or design for security vulnerabilities, (2) design a secure REST, GraphQL, or gRPC API architecture, (3) implement API authentication and authorization (OAuth2, JWT, API keys, mTLS), (4) configure rate limiting, input validation, or CORS, (5) audit API endpoints for BOLA, BFLA, or mass assignment vulnerabilities, (6) create API security checklists or verification plans, (7) fix API security bugs or harden existing APIs, (8) set up API security testing (OWASP ZAP, Schemathesis, Burp Suite), or (9) handle any API security concern including SSRF prevention, resource consumption limits, business flow protection, API inventory management, and secure third-party API consumption.

インストール方法を見る

含まれるファイル(4)

  • SKILL.md8.8 KB
  • references/api-security-checklist.md16.9 KB
  • references/owasp-api-top-10.md40.3 KB
  • references/secure-api-design.md31.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

API Security Development Guide

Structured approach to building secure APIs, covering OWASP API Security Top 10 (2023), secure design patterns, and verification checklists. Apply these guidelines throughout the API development lifecycle — from threat modeling to deployment monitoring.

Secure API Development Lifecycle

Phase 1: API Threat Modeling and Design

  • Identify API attack surfaces: public endpoints, authenticated endpoints, admin endpoints, webhooks, third-party integrations
  • Map data flows: what sensitive data crosses each API boundary
  • Define authorization model: which users/roles access which resources and properties
  • Design security controls:
    • Centralized authentication (OAuth2/OIDC at API gateway)
    • Object-level authorization at data access layer
    • Schema-based input validation at every endpoint
    • Rate limiting per endpoint sensitivity
    • API versioning with deprecation strategy

Phase 2: Secure Implementation

Critical API Security Rules

NeverInstead
Return full objects (to_dict/to_json)Explicit response schemas with cherry-picked fields
Accept arbitrary fields for updateAllowlisted update schemas (prevent mass assignment)
Use sequential/guessable IDs in URLsUUIDs/GUIDs for resource identifiers
Trust object ID alone for accessCheck object ownership against authenticated user
Rely on client-side role checksServer-side RBAC/ABAC middleware
Accept unlimited query params/bodySchema validation with size/type/range limits
Skip rate limiting on any endpointRate limit ALL endpoints, stricter on auth/business flows
Return stack traces in errorsRFC 7807 Problem Details with generic messages
Trust third-party API responsesValidate and sanitize all external API data
Put API keys in URLsUse Authorization header or secure key vault
Use wildcard CORS with credentialsExplicit origin allowlist
Allow unlimited GraphQL depth/complexityQuery depth + complexity + batch limits

Reference detailed guides:

Phase 3: API Security Verification

  1. Schema Validation — Lint OpenAPI spec for security issues (Spectral)
  2. Static Analysis — Run SAST on API code (Semgrep, bandit)
  3. Contract Testing — Verify API behavior matches spec (Schemathesis, Dredd)
  4. Dynamic Testing — Run DAST against running API (OWASP ZAP, Burp Suite)
  5. Authorization Testing — Test every endpoint with wrong user/role/anonymous
  6. Rate Limit Testing — Verify all endpoints enforce limits
  7. Code Review — Apply API security checklists

Reference: See references/api-security-checklist.md

Phase 4: Deployment and Monitoring

  • API gateway: auth offloading, rate limiting, request logging
  • TLS 1.2+ enforcement, HSTS, security headers
  • Structured logging (no tokens/PII in logs)
  • Anomaly detection and alerting on security events
  • API inventory management and version deprecation
  • Incident response plan for API breaches

OWASP API Security Top 10 (2023) Quick Reference

#RiskKey ConcernPrimary Prevention
API1Broken Object Level AuthorizationAccessing other users' resources by manipulating IDsObject ownership check at data layer, use GUIDs
API2Broken AuthenticationWeak auth, credential stuffing, JWT flawsOAuth2/OIDC, short-lived tokens, rate limit auth
API3Broken Object Property Level AuthorizationExcessive data exposure + mass assignmentExplicit response/request schemas, field allowlists
API4Unrestricted Resource ConsumptionNo rate/size/cost limits, GraphQL batchingRate limiting, pagination caps, spending alerts
API5Broken Function Level AuthorizationRegular users accessing admin functionsRBAC middleware, deny by default, test all roles
API6Unrestricted Access to Sensitive Business FlowsAutomating business-critical operations (scalping, spam)CAPTCHA, device fingerprinting, behavior analysis
API7Server Side Request ForgeryAPI fetches user-supplied URLsURL allowlisting, block private IPs, disable redirects
API8Security MisconfigurationMissing headers, CORS *, verbose errors, debug endpointsHardened defaults, security headers, minimal errors
API9Improper Inventory ManagementShadow APIs, deprecated versions, no documentationAPI inventory, OpenAPI in CI/CD, retirement plans
API10Unsafe Consumption of APIsTrusting third-party API data without validationValidate all external data, enforce TLS, set timeouts

For detailed attack scenarios and code examples: See references/owasp-api-top-10.md

API Security Review Workflow

Step-by-step procedure for reviewing API security:

  1. Map the API surface — List all endpoints, methods, auth requirements, and data flows. Check for undocumented/shadow endpoints.
  2. Check authentication — Verify every non-public endpoint requires valid authentication. Test with missing/expired/malformed tokens.
  3. Check object-level authorization (BOLA) — For every endpoint accepting resource IDs, verify users can only access their own resources.
  4. Check function-level authorization (BFLA) — Verify admin endpoints reject non-admin users. Test horizontal and vertical privilege escalation.
  5. Check property-level authorization — Verify responses only include authorized fields. Test mass assignment by sending extra fields in updates.
  6. Validate input handling — Check schema validation on all inputs. Test with oversized payloads, unexpected types, injection payloads.
  7. Check rate limiting — Verify limits on all endpoints, especially auth, business-critical, and resource-intensive operations.
  8. Check error handling — Verify no sensitive info in error responses. Test with invalid inputs, missing resources, server errors.
  9. Review third-party integrations — Verify external API responses are validated. Check for SSRF in URL-accepting endpoints.
  10. Check API inventory — Verify no deprecated/shadow endpoints are live. Check documentation matches reality.
  11. Report findings — Severity (Critical/High/Medium/Low), endpoint, vulnerable request, explanation, fix with code example.

API Security Testing Quick Commands

# === OpenAPI Spec Linting ===
npm install -g @stoplight/spectral-cli && spectral lint openapi.yaml

# === Property-based API Testing ===
pip install schemathesis && schemathesis run --checks all http://localhost:8000/openapi.json

# === Dynamic Security Scanning ===
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py -t http://target:8000/openapi.json -f openapi

# === API Fuzzing ===
# nuclei -u http://target:8000 -t api/

# === Static Analysis (Python API) ===
pip install bandit && bandit -r src/ -f json
pip install semgrep && semgrep --config=p/python --config=p/owasp-top-ten src/

Reference Files

  • references/owasp-api-top-10.md — Detailed OWASP API Security Top 10 (2023) with attack scenarios, vulnerable → secure code examples for REST and GraphQL APIs
  • references/secure-api-design.md — Secure API design patterns: authentication (OAuth2, JWT, API keys, mTLS), authorization (RBAC/ABAC), input validation, rate limiting, CORS, error handling, API gateway, monitoring
  • references/api-security-checklist.md — Actionable checklists for API design review, auth, input validation, transport security, rate limiting, inventory, deployment, logging, and testing

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Add SLSA build-provenance attestations to existing GitHub Actions workflows. Use when the user wants to add artifact attestations, build provenance, or SLSA attestations to Docker container image builds in GitHub Actions CI/CD pipelines.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Write, review, and optionally test Bash and Zsh shell scripts following project coding standards. Use for ANY shell scripting task: (1) creating a new Bash or Zsh script, (2) editing, fixing, or reviewing an existing .sh, .bash, or .zsh file, (3) adding error handling, dependency checks, or cleanup traps to shell scripts, (4) implementing API integration or file processing in shell, (5) writing or fixing ShellSpec tests (spec/*_spec.sh), or (6) deciding whether a script should be written in Bash or Zsh. Defaults to Bash; Zsh-specific guidance lives in a reference file that is loaded only when writing Zsh.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Create, run, and maintain API test collections using Bruno (OpenCollection YAML format and legacy Bru format). Use when the user wants to: (1) create a Bruno API test collection from scratch or from OpenAPI/Swagger specs, (2) write API request files with tests and assertions, (3) run API tests using bru CLI, (4) generate test reports (HTML, JUnit, JSON), (5) set up CI/CD pipelines (GitHub Actions) for automated API testing, (6) debug or fix failing Bruno API tests, (7) add environment configurations for API testing, (8) chain API requests with data extraction, or (9) work with any .yml/.bru Bruno collection files. Triggers on mentions of 'Bruno', 'bru CLI', 'API testing collection', 'OpenCollection', or requests to automate API testing with file-based collections.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Automate version bumping following semantic versioning and changelog management. Use when the user wants to bump a version, create a release, update the changelog, or tag a new version in a project using semver conventions and Keep a Changelog format.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

jim60105 のスキルをすべて見る

このスキルの問題を報告する