security-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<objective> A login test that only checks the happy path passes while an expired JWT still grants admin, an IDOR lets user A read user B's orders, and a webhook field reaches `169.254.169.254`. This skill forces the negative-path checks — broken access control, injection, SSRF, auth bypass, supply-chain drift — into CI on every PR, layered across DAST, SCA, SAST, and custom Playwright tests so no single tool's blind spot ships. It produces runnable tests mapped to the OWASP Top 10 (2025) plus the CI gates that fail the build when a category regresses. </objective>

<objective> 仅检查正常路径的登录测试会通过，但过期的JWT仍能授予管理员权限、IDOR漏洞允许用户A读取用户B的订单、Webhook字段可访问`169.254.169.254`这类场景却无法被发现。本技能将负面路径检查——包括访问控制失效、注入攻击、SSRF、认证绕过、供应链漂移——强制加入每个PR的CI流程中，通过DAST、SCA、SAST与自定义Playwright测试的分层覆盖，避免单一工具的盲区导致漏洞上线。它会生成与OWASP Top 10（2025版）对应的可执行测试用例，以及当某类漏洞复现时触发构建失败的CI门禁规则。 </objective>

Discovery Questions

探索问题

Check

.agents/qa-project-context.md

first — if it exists, use it and skip anything already answered there (auth mechanism, compliance requirements, infrastructure). Then:

Threat model: Has the team identified key assets, threat actors, and attack surfaces? If not, do a lightweight threat model before writing tests — it tells you which categories matter most.
Auth mechanism: Session cookies, JWT, OAuth 2.0/OIDC, API keys, or MFA? Each has distinct negative-path tests (alg confusion, session fixation, state tampering).
Compliance requirements: SOC 2, HIPAA, PCI DSS, GDPR? These mandate specific controls — map them with
```
compliance-testing
```
; this skill only proves the controls behave.
Existing security tooling: Already running OSV-Scanner, Snyk, Dependabot, Semgrep, or ZAP? Check CI config for existing security stages before adding duplicates.
API surface: REST, GraphQL, gRPC? Each protocol has specific injection and authorization vectors.
Deployment model: Cloud (AWS/GCP/Azure), containers, serverless? Cloud-metadata endpoints are prime SSRF targets and misconfiguration is A02.

首先查看

.agents/qa-project-context.md

——如果该文件存在，使用其中的信息并跳过已解答的问题（认证机制、合规要求、基础设施）。然后询问：

威胁模型：团队是否已识别关键资产、威胁角色和攻击面？如果没有，在编写测试前先完成轻量级威胁建模——它能告诉你哪些类别最为重要。
认证机制：使用会话Cookie、JWT、OAuth 2.0/OIDC、API密钥还是MFA？每种机制都有独特的负面路径测试（算法混淆、会话固定、状态篡改）。
合规要求：是否需要符合SOC 2、HIPAA、PCI DSS、GDPR？这些法规要求特定的控制措施——请使用
```
compliance-testing
```
进行映射；本技能仅用于验证控制措施的运行情况。
现有安全工具：是否已在运行OSV-Scanner、Snyk、Dependabot、Semgrep或ZAP？在添加重复工具前，先检查CI配置中的现有安全阶段。
API类型：REST、GraphQL还是gRPC？每种协议都有特定的注入和授权攻击向量。
部署模型：云环境（AWS/GCP/Azure）、容器还是无服务器？云元数据端点是SSRF的主要目标，配置错误属于A02类别。

Core Principles

核心原则

Security is continuous, not a phase. Scans run in CI on every PR, not as a quarterly penetration test. A vulnerability caught on the PR that introduced it costs minutes; the same vulnerability found in prod costs an incident.
OWASP Top 10 is the floor, not the ceiling. It covers the most common impactful classes. Domain-specific threats (healthcare data, financial transactions, multi-tenant isolation) need their own analysis on top.
Defense in depth — no single tool catches everything. ZAP misses auth-logic bugs, SCA misses your custom code, Semgrep misses runtime issues. Layer DAST + SCA + SAST + auth tests + secret scanning. When one layer's blind spot is another layer's coverage, a regression has to beat all of them. SCA earns its layer because most of the shipped code is third-party — known CVEs in dependencies are the lowest-effort attack vector, so scan on every build.
Shift-left. Catch each class at the earliest stage: SAST and secret scanning on commit, dependency/supply-chain checks on the PR, DAST in staging, custom auth tests on every run. See
```
shift-left-testing
```
for the dev-QA workflow this rides on.
Test the attacker, not the user. Happy-path auth proves login works. Security tests prove logout invalidates the session, an expired token is rejected, role escalation fails, and a malformed payload fails closed. The negative path IS the test.

安全是持续过程，而非阶段性任务：扫描在每个PR的CI中运行，而非每季度一次的渗透测试。在引入漏洞的PR中发现漏洞仅需数分钟修复，而在生产环境中发现则会引发安全事件，成本极高。
OWASP Top 10是底线，而非上限：它涵盖了最常见的高影响漏洞类别。特定领域的威胁（医疗数据、金融交易、多租户隔离）需要在此基础上进行额外分析。
深度防御——单一工具无法覆盖所有漏洞：ZAP会遗漏认证逻辑漏洞，SCA无法检测自定义代码问题，Semgrep会忽略运行时问题。需分层部署DAST + SCA + SAST + 认证测试 + 密钥扫描。当一层的盲区被另一层覆盖时，漏洞必须绕过所有检测才能上线。SCA的价值在于，上线的代码大多是第三方依赖——依赖项中的已知CVE是最低成本的攻击向量，因此每次构建都需扫描。
左移测试：在最早阶段发现各类漏洞：提交代码时进行SAST和密钥扫描，PR阶段进行依赖项/供应链检查，预发布环境进行DAST，每次运行都执行自定义认证测试。相关工作流可参考
```
shift-left-testing
```
。
模拟攻击者，而非普通用户：正常路径认证测试仅验证登录功能可用。安全测试需验证登出会使会话失效、过期令牌被拒绝、角色升级失败、畸形负载被拦截。负面路径本身就是测试目标。

OWASP Top 10 (2025) Testing Checklist

OWASP Top 10（2025版）测试清单

The 2025 list (final, owasp.org/Top10/2025/) re-orders categories and introduces two new ones. Changes from 2021:

A03 Software Supply Chain Failures is new (replaces "Vulnerable and Outdated Components"; broadens to provenance, build-pipeline trust, SBOM).
A10 Mishandling of Exceptional Conditions is new. SSRF is no longer standalone — its tests now sit under A01 (access control) and A06 (insecure design).
A02 Security Misconfiguration moved up from A05.
A07 Authentication Failures — name shortened (drops "Identification and").
A09 Security Logging and Alerting Failures — renamed (was "Logging and Monitoring").

For runnable test code per category, see

references/owasp-tests.md

2025版清单（最终版，owasp.org/Top10/2025/）调整了类别顺序并新增两个类别。与2021版的变化：

A03 软件供应链故障为新增类别（替代“易受攻击且过时的组件”；扩展至溯源验证、构建流水线信任、SBOM）。
A10 异常条件处理不当为新增类别。SSRF不再作为独立类别——其测试现在归属于A01（访问控制）和A06（不安全设计）。
A02 安全配置错误从A05升至第二位。
A07 认证失败——名称简化（移除“身份识别与”）。
A09 安全日志与告警失败——重命名（原名为“日志与监控”）。

每个类别的可执行测试代码请参考

references/owasp-tests.md

。

A01: Broken Access Control

A01：访问控制失效

The #1 vulnerability. Users act outside intended permissions. SSRF is now an access-control failure when the server is induced to reach internal resources for an attacker.

What to test: IDOR (change resource IDs to reach other users' data), missing function-level access control (admin endpoints as a regular user), path traversal (

../../etc/passwd

), CORS misconfiguration, SSRF (user URLs reaching internal networks, cloud-metadata endpoints,

file://

排名第一的漏洞。用户可超出预期权限操作。当服务器被诱导为攻击者访问内部资源时，SSRF属于访问控制失效。

测试内容：IDOR（修改资源ID以访问其他用户数据）、缺失功能级访问控制（普通用户访问管理员端点）、路径遍历（

../../etc/passwd

）、CORS配置错误、SSRF（用户提供的URL访问内部网络、云元数据端点、

file://

协议）。

A02: Security Misconfiguration

A02：安全配置错误

Default credentials, unnecessary features, verbose errors. Promoted from A05 — still the easiest way in.

What to test: stack traces disabled in prod, default credentials changed, unnecessary HTTP methods (e.g. TRACE) disabled, directory listing off, admin panels not public, cloud buckets not public.

默认凭据、不必要的功能、详细错误信息。从A05升至第二位——仍是最易被利用的漏洞。

测试内容：生产环境禁用堆栈跟踪、修改默认凭据、禁用不必要的HTTP方法（如TRACE）、关闭目录列表、管理面板不公开、云存储桶不公开。

A03: Software Supply Chain Failures

A03：软件供应链故障

New in 2025. Beyond "outdated dependencies" — provenance, build-pipeline integrity, the supply chain end-to-end.

What to test: lockfile committed and CI installs from it (

npm ci

, never

npm install

); SBOM generated and stored as a build artifact (Syft /

anchore/sbom-action

); provenance attestation for built artifacts (SLSA v1.0 L2/3, signed via

cosign

actions/attest-build-provenance

); dependency review on every PR; CI secrets not exposed to forks; self-hosted runners isolated from untrusted PR code.

See

references/owasp-tests.md

for the dependency-review / SBOM / provenance workflow and the lockfile-drift check.

2025版新增类别。不仅限于“过时依赖项”——涵盖溯源验证、构建流水线完整性、端到端供应链。

测试内容：提交锁文件并在CI中从锁文件安装依赖（使用

npm ci

，绝不使用

npm install

）；生成SBOM并作为构建产物存储（使用Syft /

anchore/sbom-action

）；为构建产物添加溯源证明（SLSA v1.0 L2/3，通过

cosign

actions/attest-build-provenance

签名）；每个PR都进行依赖项审查；CI密钥不暴露给分支代码；自托管运行器与不可信PR代码隔离。

依赖项审查/SBOM/溯源工作流及锁文件漂移检查请参考

references/owasp-tests.md

。

A04: Cryptographic Failures

A04：加密失败

Sensitive data exposed via weak or missing encryption.

What to test: TLS version / cipher suites / HSTS; passwords hashed with bcrypt/argon2 (not MD5/SHA1); no sensitive data in URLs, logs, or errors; cookies carry

Secure

HttpOnly

SameSite

; security headers present (HSTS,

X-Content-Type-Options: nosniff

X-Frame-Options

敏感数据因加密薄弱或缺失而暴露。

测试内容：TLS版本/密码套件/HSTS配置；密码使用bcrypt/argon2哈希（而非MD5/SHA1）；URL、日志或错误信息中不包含敏感数据；Cookie携带

Secure

、

HttpOnly

、

SameSite

属性；存在安全头（HSTS、

X-Content-Type-Options: nosniff

、

X-Frame-Options

）。

A05: Injection

A05：注入攻击

Untrusted data sent to an interpreter.

What to test: SQL injection in params/fields/headers; XSS (reflected, stored, DOM) in user content; CSRF on state-changing operations; command injection in filenames, search queries, webhook URLs.

不可信数据被发送至解释器。

测试内容：参数/字段/头中的SQL注入；用户内容中的XSS（反射型、存储型、DOM型）；状态变更操作中的CSRF；文件名、搜索查询、Webhook URL中的命令注入。

A06: Insecure Design

A06：不安全设计

Flawed architecture implementation alone can't fix. Includes design-level SSRF (URL-accepting features without an allow-list), credential stuffing without rate limits, business-logic abuse.

What to test: rate limiting on auth endpoints (fire 15 concurrent login attempts, expect a

in the responses); business-logic abuse (negative quantities, coupon stacking); account lockout after failed attempts; allow-list architecture for any feature that fetches a user-supplied URL.

仅靠架构实现无法修复的设计缺陷。包括设计层面的SSRF（接受用户提供URL的功能未配置白名单）、无速率限制的凭证填充、业务逻辑滥用。

测试内容：认证端点的速率限制（发起15次并发登录尝试，预期响应返回

）；业务逻辑滥用（负数量、优惠券叠加）；多次失败尝试后锁定账户；任何获取用户提供URL的功能都采用白名单架构。

A07: Authentication Failures

A07：认证失败

Broken authentication, weak passwords, credential stuffing. Session rotation after login, expired/

alg:none

JWT rejection, RBAC matrix, OAuth state tampering. See

references/auth-tests.md

认证机制失效、弱密码、凭证填充。登录后会话轮换、拒绝过期/

alg:none

的JWT、RBAC矩阵测试、OAuth状态参数篡改。请参考

references/auth-tests.md

。

A08: Software or Data Integrity Failures

A08：软件或数据完整性失败

Unsigned updates, insecure deserialization, untrusted CI/CD.

What to test: Subresource Integrity (SRI) on CDN scripts; Content-Security-Policy header present and free of

'unsafe-inline'

'unsafe-eval'

未签名的更新、不安全的反序列化、不可信的CI/CD。

测试内容：CDN脚本使用子资源完整性（SRI）；存在Content-Security-Policy头且未包含

'unsafe-inline'

'unsafe-eval'

。

A09: Security Logging and Alerting Failures

A09：安全日志与告警失败

Insufficient logging and missing alerts on what is logged. Renamed in 2025 to stress that logs without alerts are after-the-fact evidence, not detection.

What to test: failed logins logged AND alerting above threshold; admin actions audit-logged AND alerting on out-of-hours events; logs free of secrets/PII; the alert pipeline itself monitored.

日志不足且对已记录事件未设置告警。2025版重命名以强调：无告警的日志仅为事后证据，无法实现检测。

测试内容：失败登录被记录且超过阈值时触发告警；管理员操作被审计记录且非工作时间操作触发告警；日志中不包含密钥/PII；告警流水线自身被监控。

A10: Mishandling of Exceptional Conditions

A10：异常条件处理不当

New in 2025. Errors and unexpected states are an attack surface — fail-open defaults, uncaught exceptions leaking internals, race conditions in error paths, security checks skipped when "something went wrong."

What to test: error responses leak no stack traces / framework names / DB schema; auth fails closed (deny by default); timeouts and partial failures never bypass authorization; resource cleanup on every error path; fuzz every endpoint and verify responses stay within the documented error contract.

2025版新增类别。错误和意外状态是攻击面——默认开放的失败逻辑、未捕获异常泄露内部信息、错误路径中的竞争条件、“出现问题时”跳过安全检查。

测试内容：错误响应不泄露堆栈跟踪/框架名称/数据库 schema；认证默认拒绝（失败关闭）；超时和部分失败不会绕过授权；每个错误路径都进行资源清理；模糊测试所有端点并验证响应符合文档化的错误约定。

OWASP LLM Top 10 (2025)

OWASP LLM Top 10（2025版）

If your app embeds an LLM (chatbot, RAG, agent, copilot), the classic Top 10 above does not cover its failure modes — use the OWASP Gen AI Security Project's separate list (genai.owasp.org/llm-top-10/). This is the security/CI-gate view: one-line "what to test" per category. For the DEEP behavioral coverage of LLM01 and LLM02 — indirect injection via tool/RAG data, defend-the-tester technique, jailbreak red-teaming, and the runnable injection detector — hand off to

ai-system-testing

; do not duplicate it here.

ID	Category	What to test
LLM01	Prompt Injection	Direct + indirect injection (instructions hidden in retrieved docs, tool output, file content) override system intent. → DEEP coverage in `ai-system-testing` .
LLM02	Sensitive Information Disclosure	Model leaks PII, secrets, other tenants' data, or training data via crafted prompts. → DEEP coverage (detector, scoped tests) in `ai-system-testing` .
LLM03	Supply Chain	Provenance of models, adapters, datasets, and plugins; pinned/verified weights; poisoned third-party model or LoRA.
LLM04	Data and Model Poisoning	Training/fine-tune/RAG-ingest data integrity; backdoors and bias injected via tainted sources.
LLM05	Improper Output Handling	LLM output reaching a downstream interpreter unsanitized — XSS, SSRF, SQLi, command injection from generated text.
LLM06	Excessive Agency	Agent has more tools/permissions/autonomy than the task needs; can delete, pay, or email without a human gate.
LLM07	System Prompt Leakage	System prompt extractable, and — worse — relied on to hold secrets or enforce authz that belongs server-side.
LLM08	Vector and Embedding Weaknesses	RAG retrieval crosses tenant/permission boundaries; embedding inversion; poisoned vectors returned as context.
LLM09	Misinformation	Confident fabrication (hallucinated facts, fake citations/URLs, unsafe code) accepted as authoritative.
LLM10	Unbounded Consumption	No token/rate/cost ceilings — prompt-driven resource exhaustion, denial-of-wallet, model extraction by query volume.

LLM05 (Improper Output Handling) is where the classic Top 10 reconnects: treat LLM output as untrusted input and re-run the A05 Injection checks on anything it produces.

如果你的应用嵌入了LLM（聊天机器人、RAG、Agent、Copilot），上述经典Top 10无法覆盖其故障模式——请使用OWASP生成式AI安全项目的独立清单（genai.owasp.org/llm-top-10/）。以下是安全/CI门禁视角：每个类别对应一行“测试内容”。对于LLM01和LLM02的深度行为覆盖——通过工具/RAG数据进行间接注入、防御测试技术、越狱红队测试、可执行注入检测器——请移交至

ai-system-testing

；请勿在此重复实现。

ID	类别	测试内容
LLM01	提示注入	直接+间接注入（隐藏在检索文档、工具输出、文件内容中的指令）覆盖系统意图。→ 深度覆盖请参考 `ai-system-testing` 。
LLM02	敏感信息泄露	模型通过精心构造的提示泄露PII、密钥、其他租户数据或训练数据。→ 深度覆盖（检测器、范围测试）请参考 `ai-system-testing` 。
LLM03	供应链	模型、适配器、数据集和插件的溯源验证；固定/验证的权重；被污染的第三方模型或LoRA。
LLM04	数据与模型投毒	训练/微调/RAG摄入数据的完整性；通过受污染来源注入后门和偏见。
LLM05	输出处理不当	LLM输出未经过滤直接传入下游解释器——生成文本引发XSS、SSRF、SQLi、命令注入。
LLM06	过度自主	Agent拥有超出任务需求的工具/权限/自主性；无需人工审核即可执行删除、支付或发送邮件操作。
LLM07	系统提示泄露	系统提示可被提取，更严重的是依赖系统提示存储密钥或执行应由服务器端处理的授权逻辑。
LLM08	向量与嵌入弱点	RAG检索跨越租户/权限边界；嵌入反转；返回被污染的向量作为上下文。
LLM09	虚假信息	模型生成的虚构事实、伪造引用/URL、不安全代码被当作权威信息接受。
LLM10	无限制消耗	无令牌/速率/成本上限——提示驱动的资源耗尽、钱包拒绝服务、通过大量查询提取模型。

LLM05（输出处理不当）是与经典Top 10的衔接点：将LLM输出视为不可信输入，对其生成的内容重新运行A05注入测试。

Automated Security Scanning

自动化安全扫描

A complete pipeline layers DAST, dependency/supply-chain scanning, SAST, and secret scanning. Config and CI workflows are in

references/scanning-and-ci.md

OWASP ZAP (DAST): baseline scan against staging on every PR;
```
zap-api-scan.py
```
for APIs. ZAP 2.17.0 is current (weekly
```
w2026-MM-DD
```
Docker tags). The ZAP MCP Server (April 2026) lets coding agents drive spider/active-scan/alert-analysis for "scan the diff" workflows.
Dependency / supply-chain: OSV-Scanner is the default gate — multi-language and exits non-zero on any vuln. Add SBOM (Syft) + provenance (
```
cosign
```
/
```
attest-build-provenance
```
) for A03.
```
npm audit --audit-level=high
```
is a noisy semver-only quick check, not the gate (it won't flag non-strict-semver versions and doesn't reliably exit non-zero).
SAST: Semgrep
p/owasp-top-ten
is the SAST gate.
```
eslint-plugin-security
```
is a weak secondary signal — see the note below; keep it as a lint-time nudge, not coverage.
Secret scanning: TruffleHog with
```
--only-verified
```
in CI;
```
git-secrets
```
pre-commit.

Avoid relying on
eslint-plugin-security
as your SAST gate — as of mid-2026 it ships ~13 rules, has had no meaningful rule growth since 2020, and benchmarks put its miss rate near 90% of detectable vulnerabilities. Its 4.0.0 release is flat-config-compatible so the config runs, but layer it under Semgrep, never instead of it.

ESLint 10 (Feb 2026) removed
.eslintrc
entirely — only flat config (

eslint.config.js

) works. Any

.eslintrc.*

security config is dead on ESLint 10; use it only for repos pinned to ESLint 8. See

references/scanning-and-ci.md

for both blocks.

完整的流水线需分层部署DAST、依赖项/供应链扫描、SAST和密钥扫描。配置与CI工作流请参考

references/scanning-and-ci.md

。

OWASP ZAP（DAST）：每个PR对预发布环境进行基线扫描；使用
```
zap-api-scan.py
```
扫描API。当前版本为ZAP 2.17.0（每周更新
```
w2026-MM-DD
```
Docker标签）。**ZAP MCP Server（2026年4月）**支持编码Agent驱动爬虫/主动扫描/告警分析，实现“扫描代码差异”工作流。
依赖项/供应链扫描：OSV-Scanner为默认门禁工具——支持多语言，发现任何漏洞时返回非零退出码。添加SBOM（Syft）+ 溯源验证（
```
cosign
```
/
```
attest-build-provenance
```
）以覆盖A03类别。
```
npm audit --audit-level=high
```
是仅基于语义版本的嘈杂快速检查，不能作为门禁工具（它不会标记非严格语义版本的漏洞，且无法可靠返回非零退出码）。
SAST：Semgrep
p/owasp-top-ten
为SAST门禁工具。
```
eslint-plugin-security
```
是较弱的辅助信号——见下方说明；仅作为 lint 阶段的提示，不能作为覆盖依据。
密钥扫描：CI中使用TruffleHog并添加
```
--only-verified
```
参数；预提交阶段使用
```
git-secrets
```
。

避免依赖
eslint-plugin-security
作为SAST门禁工具——截至2026年中期，它仅包含约13条规则，自2020年以来未新增有意义的规则，基准测试显示其漏检率接近90%可检测漏洞。其4.0.0版本支持扁平配置，因此配置可运行，但需将其置于Semgrep之下，绝不能替代Semgrep。

ESLint 10（2026年2月）彻底移除了
.eslintrc
——仅支持扁平配置（

eslint.config.js

）。任何

.eslintrc.*

安全配置在ESLint 10上均无效；仅适用于固定使用ESLint 8的仓库。两种配置示例请参考

references/scanning-and-ci.md

。

Auth Testing Patterns

认证测试模式

Session management, JWT (expiry,

alg: none

confusion, wrong-key signing), and RBAC matrix tests. Full code in

references/auth-tests.md

. Also test session rotation after login (session fixation) and OAuth state-parameter tampering.

会话管理、JWT（过期、

alg: none

混淆、错误密钥签名）和RBAC矩阵测试。完整代码请参考

references/auth-tests.md

。还需测试登录后的会话轮换（防止会话固定）和OAuth状态参数篡改。

CI Integration

CI集成

A complete security pipeline has five layers, each a CI step:

Secret scanning — TruffleHog with
```
--only-verified
```
Dependency check — OSV-Scanner (fails on any vuln); SBOM + provenance for A03
SAST — Semgrep
```
p/owasp-top-ten
```
as the gate; ESLint security plugins as a weak secondary
DAST — ZAP baseline scan against staging URL
Custom auth tests —
```
npx playwright test --project=security
```

Security as PR gate: OSV-Scanner exits non-zero on any vulnerability and gates the merge directly. If you gate on

npm audit

instead, parse

npm audit --json

and

exit 1

when high/critical count > 0 —

npm audit

does not reliably exit non-zero on its own. See

references/scanning-and-ci.md

for the runnable gate.

完整的安全流水线包含五个层级，每个层级对应一个CI步骤：

密钥扫描——使用带
```
--only-verified
```
参数的TruffleHog
依赖项检查——OSV-Scanner（发现任何漏洞时失败）；添加SBOM + 溯源验证以覆盖A03类别
SAST——Semgrep
```
p/owasp-top-ten
```
作为门禁工具；ESLint安全插件作为较弱的辅助信号
DAST——ZAP对预发布URL进行基线扫描
自定义认证测试——
```
npx playwright test --project=security
```

安全作为PR门禁：OSV-Scanner发现任何漏洞时返回非零退出码，直接阻止合并。如果使用

npm audit

作为门禁工具，需解析

npm audit --json

的输出，当高/严重级漏洞数量>0时执行

exit 1

——

npm audit

本身无法可靠返回非零退出码。可运行的门禁规则请参考

references/scanning-and-ci.md

。

Anti-Patterns

反模式

Security testing only before release. Late findings are expensive. Scan every PR, not quarterly.

Relying on a single tool. ZAP misses auth-logic bugs; SCA misses custom code; ESLint misses runtime issues. Layer multiple tools.

Treating a near-dead linter as SAST coverage.

eslint-plugin-security

alone catches almost nothing (~13 rules, 2020-era detection). Gate on Semgrep

p/owasp-top-ten

; keep the linter as a nudge.

Ignoring dependency warnings. "Fix it later" becomes a backlog of known CVEs. Fail the build on high/critical via OSV-Scanner.

Testing only happy-path auth. Login works — fine. Does logout invalidate the session? Can an expired token still access resources? Does role escalation work?

Hardcoding secrets in test files. Tests holding real keys are themselves a vulnerability. Use env vars and CI secrets.

Skipping SSRF testing. Any URL-accepting feature (webhooks, image uploads, imports) is an SSRF vector. Test internal addresses and cloud-metadata endpoints.

Asserting a single status where several are valid. SSRF/CSRF/exceptional-condition tests have a set of acceptable codes. Use

expect([400, 403, 422]).toContain(response.status())

—

toBeOneOf

is not a built-in matcher and throws at runtime.

Testing only known payloads. The XSS/SQLi payloads in the references are examples, not exhaustive. Use ZAP's maintained payload database for breadth.

仅在发布前进行安全测试：后期发现漏洞成本极高。需在每个PR中扫描，而非每季度一次。

依赖单一工具：ZAP会遗漏认证逻辑漏洞；SCA无法检测自定义代码问题；ESLint会忽略运行时问题。需分层部署多个工具。

将近乎废弃的linter视为SAST覆盖依据：仅使用

eslint-plugin-security

几乎无法检测到漏洞（约13条规则，2020年的检测能力）。请使用Semgrep

p/owasp-top-ten

作为门禁工具；linter仅作为提示。

忽略依赖项警告：“以后再修复”会积累大量已知CVE漏洞。通过OSV-Scanner在发现高/严重级漏洞时触发构建失败。

仅测试正常路径认证：登录功能可用——这不够。登出是否会使会话失效？过期令牌是否仍能访问资源？角色升级是否可行？

在测试文件中硬编码密钥：包含真实密钥的测试文件本身就是漏洞。请使用环境变量和CI密钥。

跳过SSRF测试：任何接受URL的功能（Webhook、图片上传、导入）都是SSRF攻击向量。需测试内部地址和云元数据端点。

断言单一状态码（而多个状态码均有效）：SSRF/CSRF/异常条件测试有一组可接受的状态码。请使用

expect([400, 403, 422]).toContain(response.status())

——

toBeOneOf

不是内置匹配器，运行时会抛出错误。

仅测试已知 payload：参考文档中的XSS/SQLi payload仅为示例，并非 exhaustive。请使用ZAP维护的payload数据库以覆盖更多场景。

Verification

验证

Prove the assertions actually fire — a security suite that passes vacuously (wrong URL, matcher never reached) is worse than none.

Point one negative-path test at a deliberately vulnerable target and confirm it FAILS. Run a known-vulnerable app such as OWASP Juice Shop locally:
bash
```
docker run --rm -p 3000:3000 bkimminich/juice-shop
BASE_URL=http://localhost:3000 npx playwright test --project=security
```
The IDOR / injection / missing-header tests should report failures. If everything is green against Juice Shop, your assertions aren't reaching the app — fix selectors/URLs before trusting a green run against your own staging.
Confirm the matcher form runs.
```
grep -r "toBeOneOf" tests/
```
must return nothing — every acceptable-set assertion uses
```
expect([...]).toContain(...)
```
.
Confirm the gate fails on a planted vuln. Add a known-vulnerable dependency, run the OSV-Scanner step, and verify the job exits non-zero. Remove it after.

需证明断言确实会触发——空转通过的安全套件（如URL错误、匹配器未执行）比没有更糟。

将一个负面路径测试指向故意设置的漏洞目标，确认测试失败。在本地运行已知存在漏洞的应用，如OWASP Juice Shop：
bash
```
docker run --rm -p 3000:3000 bkimminich/juice-shop
BASE_URL=http://localhost:3000 npx playwright test --project=security
```
IDOR/注入/缺失头测试应报告失败。如果针对Juice Shop的所有测试均通过，说明断言未正确触达应用——在信任自身预发布环境的测试结果前，需修复选择器/URL。
确认匹配器格式正确。执行
```
grep -r "toBeOneOf" tests/
```
应无返回结果——所有可接受集合的断言均使用
```
expect([...]).toContain(...)
```
。
确认门禁在发现植入漏洞时失败。添加一个已知存在漏洞的依赖项，运行OSV-Scanner步骤，验证任务返回非零退出码。之后移除该依赖项。

Done When

完成标准

A committed
```
owasp-coverage.md
```
(or a CI job asserting it) maps every OWASP 2025 category to at least one tagged test, or to a recorded "mitigated / accepted risk" entry with justification — no category is silently absent.
OSV-Scanner (or equivalent) runs in CI and the job exits non-zero on high/critical vulnerabilities — verified by the planted-vuln check in Verification.
Semgrep
```
p/owasp-top-ten
```
runs in CI and reports zero unresolved findings on the main branch (ESLint security plugins may run as a secondary, non-gating signal).
ZAP baseline scan runs against staging and uploads its report as a CI artifact on every run (
```
if: always()
```
).
The security Playwright project (
```
--project=security
```
) exits 0 against staging AND produces failures when pointed at OWASP Juice Shop (proves assertions fire).
Auth/session edge cases each have a passing test: CSRF rejection, expired-token rejection,
```
alg:none
```
rejection, session invalidation on logout, RBAC role-escalation prevention.
No real secrets in test files (
```
grep
```
/ TruffleHog clean).

提交的
```
owasp-coverage.md
```
（或CI任务断言）将每个OWASP 2025类别映射到至少一个标记的测试用例，或记录“已缓解/接受风险”条目并说明理由——无类别被遗漏。
OSV-Scanner（或等效工具）在CI中运行，发现高/严重级漏洞时任务返回非零退出码——通过验证环节中的植入漏洞检查确认。
Semgrep
```
p/owasp-top-ten
```
在CI中运行，主分支无未解决的发现（ESLint安全插件可作为非门禁的辅助信号运行）。
ZAP基线扫描针对预发布环境运行，并在每次运行时将报告作为CI产物上传（
```
if: always()
```
）。
安全Playwright项目（
```
--project=security
```
）针对预发布环境返回0，且针对OWASP Juice Shop时产生失败结果（证明断言会触发）。
每个认证/会话边缘场景都有通过的测试：CSRF拒绝、过期令牌拒绝、
```
alg:none
```
令牌拒绝、登出时会话失效、RBAC角色升级阻止。
测试文件中无真实密钥（
```
grep
```
/ TruffleHog检查通过）。