An API security check that stops at “the token was valid” has not checked whether the token could access this object, whether a batch endpoint bypasses the same rule, or whether a failure disclosed too much.
Why this Skill is needed
The API Security Testing Skill reviews the boundary between caller identity, requested object, input, response, and operational controls. It prepares bounded AST-## scenarios and keeps unauthorized or destructive actions outside the workflow until they are explicitly approved.
What the Skill does
Use this Skill when a team needs to review authentication, authorization, object scope, input exposure, secrets, rate limits, error leakage, or audit evidence for an API.
A thorough review follows one object across the full request: who owns it, who may act on it, which alternate entry points exist, what a failure reveals, and which audit record proves the decision. A 403, an OpenAPI document, or a valid token alone is not comprehensive security evidence.
What it does not do
It does not replace:
- Penetration testing, red-team action, vulnerability scanning, or an authorized exploit.
- An unauthorized call to a real API or a production probe.
- Security requirement review, threat modeling, or permission design.
- Risk acceptance, exception approval, or release-security judgment.
- Complete runtime security assurance outside the supplied request boundary.
What it checks
| Focus | Question | Handoff output |
|---|---|---|
| Attack surface | Which path, query, body, header, upload, batch, or alternate endpoint accepts input? | Inventory and boundary |
| Input boundary | What malformed, oversized, encoded, repeated, or unexpected input must be handled? | Safe scenario and oracle |
| Authentication | Who issued the token, and what do its subject, tenant, and lifecycle show? | Identity and token evidence |
| Authorization | Can this caller perform this action? | Role and action policy |
| Object authorization | Can the caller access this specific object, including across tenant boundaries? | Ownership matrix and allow/deny evidence |
| Error and response | What do status, body, timing, headers, URLs, and logs reveal on failure? | Leakage check and evidence |
| Rate limits and abuse | How are repeated, bulk, unusually frequent, or resource-heavy requests handled? | Bounded scenario and expected limit |
| Audit | Can a security-relevant action be traced without exposing excess data? | Audit event and evidence path |
| Security contract | Can authentication, permission, data, error, rate, and audit rules trace to verification? | AST finding and close condition |
The matrix turns a security label into a request that can be authorized, executed, and reviewed.
Audit inputs before you start
| State | Meaning | Handling |
|---|---|---|
| known | Directly supported by an API contract, policy, sample, or run record | Preserve source, version, and identity |
| missing | Needed for the scenario but not supplied | Record the gap and stay in preparation |
| conflicting | OpenAPI, permission matrix, and security requirement disagree | Preserve all sources and request a decision |
| stale | Token shape, endpoint, policy, or environment is old | Mark freshness before using it |
| out_of_scope | Production calls, real credentials, intrusive payloads, or destructive actions | Exclude unless separately authorized |
| assumptions | Synthetic tenant, object, role, or isolated environment is assumed | State the assumption and stop condition |
Input templates and request examples are not execution evidence. A safe analysis can continue, but it must say what still needs an authorized run.
From problem to structured Finding
Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.
Keep the decision layers separate
| Layer | How to write it | Example |
|---|---|---|
| Fact | What the contract or request material directly shows | The endpoint accepts a token and job_id |
| Evidence-backed Inference | What the missing binding could allow | Authentication may be implemented without object authorization |
| Recommendation | The smallest safe next action | Define tenant binding, error semantics, audit fields, and a synthetic validation |
| Human Decision | What requires authorization or risk choice | Owners approve environment, account scope, and leakage trade-off |
Do not label a request sent, a 403 returned, or a template generated as a complete security pass.
A complete case
This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.
Input
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Security model | Identity, role, tenant, resource ownership, and allowed operations | Keep policy ambiguity open |
| Attack surface | Path, query, body, headers, file names, batch behavior, and error responses | Include malformed and overlong inputs |
| Evidence | Allow and deny logs, redaction, rate-limit events, and account matrix | Do not infer protection from middleware names |
| Authorization boundary | Isolated environment, synthetic data, account scope, and stop conditions | Do not use production as a shortcut |
Use a request like this:
Use the api-security-testing Skill.
Task: Review a document-download API shared by employees, contractors, and service accounts across tenants.
Inputs: [API contract, versions, permission matrix, redacted requests, logs, reports, or data paths]
Scope: [included and excluded objects]
Unknowns: [missing environment, accounts, data, or permissions]
Expected output: [AST-## findings, evidence status, safe validation, and next actions]
Audit the inputs first. Separate facts, assumptions, and open questions. Do not claim execution without an authorized run record.Analysis
Use the input, matrix, and evidence state to form the judgment before writing the Finding; keep missing material as a gap.
Finding
Example finding: AST-02 exposes an object-authorization gap
Suppose the contract contains:
GET `/exports/{job_id}/download`
Authorization: Bearer <token>The materials do not explain how job_id is bound to the caller’s tenant, whether a cross-tenant object returns 403 or 404, or whether the failure response reveals object existence. This is an illustrative preparation pattern, not an exploit result.
AST-02 — Download authorization and error leakage are underspecified
| Field | Example |
|---|---|
| Object and rule | GET /exports/{job_id}/download and tenant-owned export access |
| Source | API Contract v3.2; token description supplied, object matrix and error contract missing |
| Trigger | Tenant A requests Tenant B’s job_id, a nonexistent job_id, and an expired job_id |
| Expected concern | Authentication success must not bypass object authorization; failure should not overexpose existence or sensitive fields |
| Evidence state | missing |
| Impact and priority | API, gateway, audit, and client may implement different failure semantics; the example provides no impact assessment or priority rubric, so priority remains unassigned |
| Owner and decision | API, security, and tenant-authorization owners choose enforcement point and 403, 404, or uniform-error strategy |
| Close condition | Authorization, error, audit, and sensitive-data rules are explicit in the contract |
| Validation | In an authorized isolated environment use synthetic tenants and files; retain raw responses, audit records, version, time, and stop conditions |
This finding does not claim a vulnerability exists. It says the current evidence cannot yet support a reviewable object-authorization test.
Decision
The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.
Validation
Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.
How a Finding enters the next stage
Handoff output
At minimum, hand off the source, evidence state, owner, close condition, and validation action; the route still needs an accountable owner.
Next-stage route
- Audit the API contract, permission matrix, and redacted request or response.
- Produce AST-## scenarios with preconditions, stimulus, expected result, evidence, and stop conditions.
- Have the accountable owner confirm environment, accounts, data, and authorization.
- Run in an isolated environment with minimum privilege and synthetic data.
- Record response, audit log, version, time, and residual risk separately from the preparation.
The Skill prepares step 4. It does not perform step 4 by implication.
How to prepare better input
Provide the API contract and version, endpoint scope, role and tenant matrix, object ownership, input fields, data classification, rate policy, audit fields, redacted samples, history, authorized environment, synthetic data, account scope, and stop conditions.
A useful handoff keeps target, object, in/out scope, evidence states, AST finding, owner, close condition, expected result, and validation method together.
Working with other Skills
- Security Requirement Review: https://inaodeng.com/en/qaskills/security-requirement-review/
- Threat Modeling: https://inaodeng.com/en/qaskills/threat-modeling/
- Authorization Testing: https://inaodeng.com/en/qaskills/authorization-testing/
- Secrets Exposure Review: https://inaodeng.com/en/qaskills/secrets-exposure-review/
Common traps
- Treating a valid token as proof that the caller can access this object.
- Testing the UI while ignoring direct, batch, background, and download entry points.
- Treating 403 as proof that every object is safe, without checking 404 and error leakage.
- Listing attack names without trigger, expected result, evidence, and stop conditions.
- Using real credentials or production APIs to fill a missing material gap.
Install and invoke
npx skills add naodeng/awesome-qa-skills --skill api-security-testingInstallation and troubleshooting:
- README: https://github.com/naodeng/awesome-qa-skills/blob/main/README_EN.md
- FAQ: https://github.com/naodeng/awesome-qa-skills/blob/main/FAQ_EN.md
- Installation guide: https://github.com/naodeng/awesome-qa-skills/blob/main/scripts/INSTALL_SKILLS_EN.md
Use the api-security-testing Skill.
Include objective, endpoint scope, versions, evidence paths, constraints, and authorization boundary.
Audit inputs first. Return AST-## findings with trigger, expected result, evidence state, owner, stop condition, and safe validation method.FAQ
Does a 403 prove that the resource is protected?
No. Confirm the identity, object ownership, version, alternate entry points, response body, timing, and audit record.
Can the Skill perform an attack?
No. It provides evidence-bounded analysis and validation preparation. Intrusive actions require explicit authorization, safe data, and a controlled environment.
References
The Skill does not log in with real credentials, read secrets, call production APIs, or perform destructive probing. Static contracts, request templates, and dry runs remain planning or material evidence; they do not prove an attack occurred, a vulnerability is absent, or a release was approved.
- API Security Testing prompt (execution contract): https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-security-testing/prompts/api-security-testing.md
- API Security Testing Skill source directory (definition, prompt, agent adaptation, and evaluation assets): https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-security-testing
- API Security Testing details: https://inaodeng.com/en/qaskills/api-security-testing/
- Awesome QA Skills project: https://github.com/naodeng/awesome-qa-skills