The short answer
Paqad's security review is organised around public OWASP guidance. OWASP (the Open Worldwide Application Security Project) publishes widely used lists and test guides for web and API security. Paqad's review skills point the AI at specific OWASP test IDs and risk categories, so that the review looks in known places and the report uses shared names.
That is a map of where the review looks. It is not proof that your application is secure, not a certification, and not evidence of compliance with any standard. Paqad does not claim to cover every OWASP category fully, and this page does not label any category as covered.
Which OWASP guides are referenced
- Web Security Testing Guide (WSTG). A catalogue of individual tests with IDs such as
WSTG-INPV-05(SQL injection). The report's coverage matrix and several skills use these IDs. - OWASP Top 10 (2025). The ten most common web application risk categories. Some skills name the category they relate to.
- OWASP API Security Top 10 (2023). The equivalent list for APIs, referenced by the access control and rate limiting skills.
- OWASP ASVS. The Application Security Verification Standard, referenced as background for logging and in the security expert notes.
What each review skill references
This table lists only the references written into the skill files shipped with paqad-ai 1.91.1. Where a skill names no OWASP Top 10 category, none is given here.
| Skill | What it looks at | OWASP references in the skill |
|---|---|---|
permission-boundary-review | Access to other users' records, function-level permissions, mass assignment, resource consumption | API Security 2023 #1, #3, #4, #5 |
input-validation-review | Injection, SSRF, IDOR, mass assignment, file upload, prototype pollution, ReDoS | WSTG-INPV-05, 06, 12, 13, 17, 18, 19; WSTG-AUTHZ-04; WSTG-BUSL-09 |
auth-mechanism-review | JWT handling, sessions, OAuth, brute force, password rules, token storage | WSTG-SESS-03, 09, 10; WSTG-ATHN-03, 07 |
cryptographic-review | Password storage, encryption, random numbers, key management, TLS | Top 10 2025 A04; WSTG-CRYP-01 to 04; WSTG-ATHN-07 |
logging-monitoring-review | Audit trails, log injection, sensitive data in logs, alerting | Top 10 2025 A09; ASVS section 7.1 |
rate-limiting-review | Missing throttling on login, bulk and expensive endpoints | API Security 2023 #4 |
runtime-surface-probing | Security headers, TLS, exposed debug and admin paths | Top 10 2025 A02 (headers), A04 (TLS) |
dependency-advisory-triage | Known advisories, typosquatting, dependency confusion, abandoned packages | Top 10 2025 A03 (supply chain signals) |
business-logic-abuse-review | Race conditions, workflow bypass, financial manipulation | WSTG-BUSL-01 to 12 (in the report matrix) |
stride-threat-model | Threats per module by STRIDE category | None (STRIDE is a separate threat modelling method) |
Findings can carry an optional wstg_id and an optional owasp_2025 field, filled in by the AI when it normalises findings.
How to read the report's coverage matrix
Every report includes a WSTG coverage matrix. Each row is a test ID with a status of covered or blocked.
coveredmeans the review attempted that check with the evidence it had.blockedmeans it could not, for example because no running app was available.
Neither status says the application passed the test. A row marked covered can still hide a problem the AI did not spot. The review is AI judgment supported by pattern-matching scripts, so its depth depends on the model, your documentation and the tools installed.
Using the mapping well
- Use the OWASP references to decide what to test by hand and what to ask a professional tester to focus on.
- Keep the reports with your other security records, but do not present them as an audit or certification.
- Run a retest after fixes so each finding ID gets a fresh status. See The security review workflow.