api-security-testing

API Security Testing (Chinese Version)

When to Use

When you need to design security testing or review preparation around the API attack surface, input boundaries, identity and permissions, error leakage, and security contracts.
When you need to deliver a reviewable initial version when materials are incomplete, and clearly state assumptions, gaps, and Human decisions.
When you need to distinguish static security evidence, planned validation, and execution that has already occurred.

By default, output Markdown organized by security risk, evidence, and priority.
When the user requests table, CSV, JSON, or ticket formats, retain the same finding fields and evidence status.
Before output enters an automated process, first confirm the schema, enum values, and required fields.

First read prompts/api-security-testing.md, and execute the input audit, coverage checklist, and output contract.
Extract scope, environment, version, roles, data, dependencies, constraints, and available evidence.
Build reviewable scenarios around the API attack surface, input boundaries, identity and permissions, error leakage, and security contracts, distinguishing known facts, inferences, and candidate validations.
For each item, record impact, priority, responsible role, closure conditions, and validation method.
When information is insufficient, deliver a limited initial version, and do not write risk assumptions as vulnerability confirmations or security passes.

Each execution must read prompts/api-security-testing.md.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory exists and the task requires it.

From the provided API inventory, build a table of endpoints, principals, resources, actions, sensitive fields, and trust boundaries, marking whether identity comes from the server side or from a controllable request.
Each risk must have a provided entry point, principal/resource/action, boundary path, applicable security obligations, and evidence; a static candidate does not equal a vulnerability confirmation.
When forming domain candidates, you must read and follow prompts/api-security-testing.md the domain operations and determination process, retaining legitimate controls, evidence gaps, and validation actions item by item.

Only analyze the API attack surface, input boundaries, identity and permissions, error leakage, and security contracts; do not log in to systems, do not call real APIs, and do not read credentials.
Do not fabricate vulnerabilities, successful attacks, completed fixes, scan coverage, or security pass conclusions.
When evidence is lacking, mark as pending confirmation, blocked, or unassessed, and provide an isolated validation method.
Risk acceptance, exception authorization, and release decisions must be left to Human.

Completed the known, missing, conflicting, stale, out_of_scope, and assumptions audit.
Covered API security, trigger conditions, expected focus points, and evidence status.
Separated facts, inferences, recommendations, information gaps, and Human decisions.
Did not write static findings or dry-runs as real attacks, absence of vulnerabilities, or release approval.

Treating a generalized security review or API contract check as a complete substitute for API security testing.
List only attack names, without writing the scope of applicability, evidence, expected results, and closure conditions.
When information is insufficient, directly determine that it is safe, or read real credentials for the sake of completeness.

Start from high-impact, hard-to-detect, privilege-sensitive, or data-sensitive paths.
Use sanitized materials, least privilege, isolated environments, and rollback-capable validation recommendations.
Enable another engineer to review each security conclusion based on its source and boundaries.