owasp-security-review

Review code and architectures against the OWASP Top 10:2025 — the ten most critical web application security risks. Use when: (1) reviewing code for security vulnerabilities, (2) auditing a feature or codebase against OWASP categories, (3) providing remediation guidance for identified vulnerabilities, (4) writing new code and needing secure coding patterns. Triggers: 'review for security', 'OWASP audit', 'check for vulnerabilities','security checklist', 'is this code secure', 'security review', 'fix vulnerability'.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "owasp-security-review" with this command: npx skills add jgamaraalv/ts-dev-kit/jgamaraalv-ts-dev-kit-owasp-security-review

OWASP Top 10:2025 Security Review

<quick_reference>

Quick reference

#CategoryKey riskAvg incidence
A01Broken Access ControlUnauthorized data access, privilege escalation, SSRF, CSRF3.74%
A02Security MisconfigurationDefault creds, verbose errors, missing hardening, XXE3.00%
A03Software Supply Chain FailuresVulnerable/malicious dependencies, compromised build pipelines5.72%
A04Cryptographic FailuresWeak algorithms, hardcoded keys, missing encryption, weak hashing3.80%
A05InjectionSQLi, XSS, command injection, LDAP/XPath/EL injection3.08%
A06Insecure DesignMissing threat modeling, business logic flaws, insufficient controls1.86%
A07Authentication FailuresCredential stuffing, weak passwords, session fixation, missing MFA2.92%
A08Software/Data Integrity FailuresUnsigned updates, insecure deserialization, untrusted CDN code2.75%
A09Security Logging & Alerting FailuresMissing audit logs, no alerting, log injection, sensitive data in logs3.91%
A10Mishandling of Exceptional ConditionsFailing open, info leakage via errors, unchecked return values2.95%

Severity classification

Use these severity levels when reporting findings:

  • Critical: Directly exploitable, leads to full system compromise or mass data breach (e.g., SQLi with no parameterization, hardcoded admin credentials, missing auth on admin endpoints).
  • High: Exploitable with moderate effort, significant data exposure or privilege escalation (e.g., IDOR, weak password hashing, SSRF, deserialization of untrusted data).
  • Medium: Exploitable under specific conditions, limited impact (e.g., missing CSRF protection, verbose error messages, missing security headers).
  • Low: Defense-in-depth issue, minimal direct impact (e.g., missing rate limiting, incomplete logging, suboptimal crypto configuration).

</quick_reference>

<workflow>

Workflows

<phase_1_code_review>

Code review for security

Systematically check the code against each relevant category:

  1. Identify the code's surface area — Does it handle auth? User input? File uploads? External data? Crypto? Error responses?
  2. Select relevant categories from the table above based on the surface area.
  3. Load the reference file for each relevant category and check the code against the "What to look for" section.
  4. Report findings grouped by category with severity (Critical/High/Medium/Low), the specific code location, and a concrete fix.

Priority order for review (highest impact first):

  • [CRITICAL] Input handling code → A05 (Injection), A01 (Access Control)
  • [CRITICAL] Auth/session code → A07 (Authentication), A01 (Access Control)
  • [HIGH] Data storage/transmission → A04 (Cryptographic Failures)
  • [HIGH] Configuration/deployment → A02 (Security Misconfiguration)
  • [HIGH] Dependencies → A03 (Supply Chain)
  • [MEDIUM] Error handling → A10 (Exceptional Conditions), A09 (Logging)
  • [MEDIUM] Architecture/design → A06 (Insecure Design)
  • [MEDIUM] Data integrity → A08 (Integrity Failures) </phase_1_code_review>

<phase_2_audit_checklist>

Security audit checklist

Generate a checklist for a feature or codebase:

  1. Read the feature/codebase to understand its scope.
  2. For each of the 10 categories, determine if it applies.
  3. For applicable categories, load the reference file and produce a checklist of items to verify.
  4. Output a markdown checklist grouped by category. </phase_2_audit_checklist>

<phase_3_remediation>

Remediation guidance

When a vulnerability is identified:

  1. Classify it into the correct OWASP category.
  2. Load the corresponding reference file.
  3. Apply the prevention checklist to produce a specific, actionable fix.
  4. Provide a code example of the fix when possible. </phase_3_remediation>
</workflow> <references>

Reference files

Load the relevant file when you need detailed guidance for a specific category:

</references> <output> When reporting security findings, use the template in [template.md](template.md) for each finding. </output>

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

bullmq

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

ui-ux-guidelines

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

ioredis

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

service-worker

No summary provided by upstream source.

Repository SourceNeeds Review