Security Owasp Web

Security: OWASP Web Top 10

Purpose

Review a web, API, or mobile-backend surface against the current OWASP categories. Give each applicable category a status backed by code, configuration, or test evidence, then assign remediation and residual risk.

Scope and evidence

1. Read references/owasp-web-top10.md.
2. Pull the platform matrix from platform-detector and the architecture views from architecture-review.
3. Pull dependency manifests, CI configs, IAM/RBAC definitions, auth flows, and observability surfaces. Read-only.
4. Use Context7 MCP to confirm current OWASP wording and any framework's current security guidance (Spring, Django, FastAPI, Express, Rails, Next.js, Phoenix, etc.).

Assessment

1. For each Top 10 category, collect evidence: route to the relevant files/configs without writing.
2. Mark per-category status: Pass, Concern, Fail, Out-of-scope.
3. For Concern/Fail, name: file/config path, what is wrong, blast radius, exploit path sketch, mitigation, owner, and verification test.
4. Cross-check with security-secrets, cve-zero-day-scanner, and infrastructure-as-code for shared concerns (secrets, dependencies, IAM).
5. Produce a remediation plan ordered by exploit risk × ease of fix.
6. Hand off to service-implementation for fixes and qa-eval for security test cases.

Safety rules

• Use Context7 MCP for the current OWASP categories, definitions, and framework-specific guidance. Treat references/owasp-web-top10.md as a local checklist, not the authority of record.
• Keep a decision trace: source documents, framework version, what was checked, what was not checked, and why.
• Refuse to "approve" a category without a named artifact and verification test.
• Escalate before authorizing a release with any unmitigated High finding.

Security record

• Per-category status table (Pass/Concern/Fail/Out-of-scope) with evidence paths
• Findings register: severity, exploit sketch, mitigation, owner, verification test
• Remediation plan ordered by risk × ease
• Cross-links to security-secrets, cve-zero-day-scanner, infrastructure-as-code
• Release gate verdict: Go / Conditional / Hold

Release criteria

• No category marked Pass without an evidence path and a verification test.
• No High finding silently accepted; every accepted risk needs a named approver and expiry.
• No security test that only mocks the vulnerable boundary.
• No release gate verdict without naming the platform, version, and date evaluated.

Handoff

Hand off to service-implementation per finding with: file path, mitigation, verification test, rollback note. Hand off the release-gate verdict to qa-eval and pr-review.

References

• references/owasp-web-top10.md: per-category checklist, framework-specific notes, and verification-test patterns.