Security Audit

OWASP Security Audit - Main Skill

This skill orchestrates the application security analysis according to the OWASP Top 10 (2025). It coordinates 10 category reference guides (references/A0X-*.md) and produces a structured vulnerability report.

Step 1 - Context Gathering

Before any analysis, identify the context available. If the user has provided only limited information, ask at most 4 targeted questions before starting, do not block the analysis if the context is sufficient. The report level and language can be combined into a single question.

Information to collect:

• Nature of the target: source code / architecture / configuration / functional description
• Language(s) and framework(s) used
• Desired scope: complete analysis (A01 to A10) or specific category/categories
• Desired report level: executive (summary) / technical (detailed) / exhaustive (with complete remediation)
• Report language: ask for the desired language (default: English). Options: English, French, Spanish. Store the choice and apply it to the entire report (Step 5), including the Execution Context validation prompts (Step 2).

If the context is partial, perform the analysis on what is visible and flag the limitations in the "Limitations" section.

Step 1.5 - Technical Stack Detection

Identify the stack before analyzing in order to prioritize the most relevant patterns and avoid false positives caused by incorrect context.

Signals to detect

# Identify the main language(s)
find . -type f \( -name "*.php" -o -name "*.py" -o -name "*.java" -o -name "*.go" -o -name "*.ts" -o -name "*.js" -o -name "*.rb" \) | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -10

# Node.js / TypeScript
grep -rn "mongoose\|prisma\|sequelize\|typeorm\|redis" --include="*.js" --include="*.ts" -l 2>/dev/null
grep -rn "graphql\|apollo\|nexus\|pothos" --include="*.js" --include="*.ts" -l 2>/dev/null
grep -rn "openai\|anthropic\|langchain\|mistral\|ollama" --include="*.js" --include="*.ts" -l 2>/dev/null
grep -rn "fetch\|axios\|got\|node-fetch" --include="*.js" --include="*.ts" -l 2>/dev/null

# PHP / Laravel / Symfony
grep -rn "Illuminate\|Symfony\|Laravel\|Doctrine\|PDO\|mysqli" --include="*.php" -l 2>/dev/null
grep -rn "unserialize\|eval\s*(\|system\s*(\|exec\s*(" --include="*.php" -l 2>/dev/null

# Python / Django / Flask / FastAPI
grep -rn "django\|flask\|fastapi\|sqlalchemy\|pymysql\|psycopg" --include="*.py" -l 2>/dev/null
grep -rn "pickle\|subprocess\|os\.system\|eval\s*(" --include="*.py" -l 2>/dev/null

# Java / Spring
grep -rn "springframework\|hibernate\|jpa\|jdbc" --include="*.java" -l 2>/dev/null
grep -rn "ObjectInputStream\|Runtime\.exec\|ProcessBuilder" --include="*.java" -l 2>/dev/null

# Go
grep -rn "database/sql\|gorm\|gin\|echo\|fiber" --include="*.go" -l 2>/dev/null
grep -rn "exec\.Command\|os/exec" --include="*.go" -l 2>/dev/null

# Frontend JS frameworks - React / Vue / Angular / Next.js / Nuxt
grep -E '"(react|vue|@angular/core|next|nuxt|@nuxtjs)' package.json 2>/dev/null | head -10

# Next.js - detect the presence of server code
ls pages/api 2>/dev/null && echo "NEXTJS_PAGES_API_ROUTES"
ls app/api 2>/dev/null && echo "NEXTJS_APP_API_ROUTES"
grep -rln "getServerSideProps\|getStaticProps\|'use server'\|server-only" --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null | head -10
grep -rn "NEXT_PUBLIC_" .env* 2>/dev/null | grep -iE "secret|key|token|password|api" | head -10

# Nuxt.js - detect server routes
ls server/api server/routes 2>/dev/null | head -5
grep -rln "defineEventHandler\|useServerApi\|serverApi" --include="*.js" --include="*.ts" 2>/dev/null | head -5

# Angular - is SSR enabled?
grep -E '"@angular/ssr|@nguniversal' package.json 2>/dev/null

# Secrets exposed client-side (all frameworks)
grep -rn "REACT_APP_\|VUE_APP_\|VITE_\|NEXT_PUBLIC_" .env* 2>/dev/null | grep -iE "secret|key|token|password|api" | head -10
grep -rln "localStorage\.setItem\|sessionStorage\.setItem" --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null | head -5

Role of JS frameworks: SSR vs CSR

Before analyzing a project using React, Vue, Angular, Next.js, or Nuxt, determine the execution mode: it radically changes the attack surface.

Signals for identifying the role

Presence of pages/api/ or app/api/          → Next.js with API routes (genuine server code)
Presence of 'use server' or server-only     → Next.js Server Actions / Server Components
getServerSideProps in the pages             → Server-side rendering with possible access to the DB/env
server/api/ or defineEventHandler           → Nuxt.js with server routes
@angular/ssr in package.json                → Angular Universal (SSR)
Absence of all of the above + React/Vue     → Pure SPA (CSR only)

Impact on the analysis: what not to do

• Do not apply injection/SSRF patterns to React/Vue/Angular code that is purely CSR: these vectors do not exist on the browser side
• Do not ignore Next.js API routes on the grounds that "it's just React": they are genuine server endpoints to be analyzed like Express
• Check the NEXT_PUBLIC_*, REACT_APP_*, VITE_* variables: anything carrying this prefix is bundled into the client and potentially accessible to the user

Stack -> priority patterns matrix

If the context is insufficient to identify the stack, note it in "Limitations" and analyze using generic patterns.

Quick Triage - Critical Patterns to Check First

Before the category-by-category analysis, check these high-impact patterns:

These patterns are high-yield starting points for Critical findings. Identify them first, then analyze the remaining categories.

Step 2 - Detection of the Execution Environment

Before running any runtime verification command, resolve an Execution Context and keep it for the entire audit. Static analysis of the workspace does not require this context, but must never be confused with runtime checks.

Command classification

Hard rule: never execute a runtime command until the Execution Context is resolved and the user has explicitly validated that specific command. Never silently run runtime tools on the host when the project is dockerized.

Automatic detection (ordered)

Run these checks (infra/static; announce if they need elevated permissions):

# 1. Already inside a container?
ls /.dockerenv 2>/dev/null && echo "IN_CONTAINER"
cat /proc/1/cgroup 2>/dev/null | grep -qiE 'docker|podman|containerd' && echo "IN_CONTAINER"

# 2. Project dockerized signals
ls Dockerfile Dockerfile.* docker-compose.yml docker-compose.yaml compose.yml compose.yaml .dockerignore 2>/dev/null
ls -d .devcontainer 2>/dev/null && echo "DEVCONTAINER_PRESENT"

# 3. Container CLI availability: pick the first available in this order: docker > podman > nerdctl
if command -v docker >/dev/null; then CLI=docker
elif command -v podman >/dev/null; then CLI=podman
elif command -v nerdctl >/dev/null; then CLI=nerdctl
else CLI=none; fi
echo "CLI=$CLI"

# 4. Running containers / compose services (replace $CLI)
$CLI ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" 2>/dev/null
$CLI compose ps 2>/dev/null

If the CLI is missing, the daemon is down, or permission is denied: record it in Limitations, do not silently assume a healthy Docker runtime. If the project is dockerized, warn strongly and ask the user whether to continue on the host.

App service selection (Rule C)

When Compose (or multiple containers) is present:

1. Prefer services that look like application runtimes (Node / PHP / Python / Java / Go / Ruby images or builds, WORKDIR, HTTP ports).
2. Exclude pure infra roles by default (db, redis, mail, mysql, postgres, mongo, elasticsearch, etc.).
3. Auto-propose the best single candidate.
4. If several plausible app services exist: list them and ask the user which to target.

Decision tree

Already IN_CONTAINER?
├── Yes → mode = in-container (current container)
└── No → project dockerized (Dockerfile / Compose / .devcontainer)?
    ├── No → mode = host (native)
    └── Yes → containers / services running?
        ├── Yes → select service (Rule C)
        │         → mode = docker-exec (compose exec or exec)
        └── No → ASK the user:
              (1) Start the required services, then test inside
              (2) Test outside Docker (host)
              If (1) → propose `$CLI compose up` (or equivalent), require validation,
                       wait for healthy services, then select service (Rule C)
              If (2) → compare host versions vs Dockerfile/Compose declared versions,
                       warn on mismatch, confirm, then mode = host

Memorize the resolved context for the whole audit. Recall it in every runtime validation prompt.

Execution Context contract

Fill this block once in Step 2; reuse it for every dynamic check and pass it to every sub-agent:

Execution Context:
- mode: host | docker-exec | in-container
- project_dockerized: yes | no
- compose_file: <path|none>
- target_service: <name|none>
- target_container: <name|id|none>
- container_cli: docker | podman | nerdctl | none
- exec_prefix: "" | "<cli> compose exec -w <cwd> <service>" | "<cli> exec -w <cwd> <container>"
- working_directory: <path inside runtime>
- runtime_versions: { node: ..., php: ..., python: ... }
- host_vs_declared_diff: none | warned | accepted
- notes: [...]

Rule: every runtime command is executed as exec_prefix + command (when exec_prefix is empty, the command runs in the current context: host or in-container).

Working directory resolution

Before any exec, resolve working_directory in this order:

1. Compose service working_dir if set
2. Dockerfile WORKDIR for the target image/build
3. Project root as mounted in the container (from volume mounts when available)
4. Fallback: / only if unknown; state this in Limitations / notes

Version comparison (host fallback while project is dockerized)

When the user chooses option (2) host testing:

1. Read declared runtimes from Dockerfile / Compose (FROM node:20, php:8.3, Python image tags, etc.).
2. Probe host versions (node -v, php -v, python --version, …) only after announcing them and getting validation if treated as execution.
3. On major or clearly incompatible mismatch: warn and ask confirmation.
4. Set host_vs_declared_diff to warned or accepted.
5. Mention the mismatch in the report Limitations section.

Edge cases (mandatory)

Mandatory validation rules before any execution

Never execute a command without:

1. Announcing the command and its purpose
2. Specifying the Execution Context (mode, service/container, working dir, exec_prefix)
3. Requesting explicit validation from the user
4. In case of failure, analyzing the error before reporting it as a finding

Validation request format (use systematically for runtime and infra commands that change state):

I would like to execute the following command to verify [objective]:
→ Context : [host | compose exec <service> | exec <container> | already in-container]
→ Working dir : [<path>]
→ Command : `<full command including prefix>`
→ Runtime : [node X / php Y / … from chosen context]
→ Reason  : [OWASP category + what it verifies]
→ Note    : [version mismatch warning if any]

Do you confirm? (yes / no / modify / switch to host|container)

Step 3 - Loading the Sub-skills

Each OWASP category has a dedicated reference guide in references/. Read the corresponding file before analyzing each category.

Recommended reading order:

• Complete analysis → read all reference guides sequentially (A01 to A10)
• Targeted analysis → read only the relevant reference guide(s)
• Quick triage → read A01, A02, A03 as a priority (the most frequently exploited categories)

Analysis Orchestration

Announce progress at the start of each category:

🔍 [X/10] Analyzing A0X - Category name...

Modest-sized codebase (< 50 source files) → sequential analysis: read the reference guide, analyze the category, document the findings, then move on to the next one.

Large codebase (> 50 source files) → dispatch one sub-agent per OWASP category via the Agent tool:

• Each sub-agent receives: the reference file (references/A0X-*.md) + the scope + the quick triage results + the full Execution Context block from Step 2
• Instruct each sub-agent: runtime commands must use exec_prefix; static analysis may use the host workspace; never invent findings from failed execs
• Each sub-agent returns its findings in the OWASP-A0X-NNN format
• Aggregate and deduplicate the findings before producing the report (Step 5)
• If a dynamic check could not run because of context limits, keep ⚪ Low confidence / [MANUAL VERIFICATION REQUIRED] and note it in Limitations

Step 4 - Analysis by Category

For each OWASP category analyzed:

1. Read the corresponding reference guide (references/A0X-*.md)
2. Apply the detection patterns defined in the reference guide
3. If a dynamic check is relevant, follow the Step 2 protocol (Execution Context already resolved + per-command validation). Runtime commands must use exec_prefix.
4. Classify each finding according to the severity grid below
5. Document it according to the report format (Step 5)

Severity Grid

Confidence Levels

Assign a confidence level to each finding to distinguish certainties from suspicions:

Remediation Effort

Estimate the cost of the fix to help prioritize high-impact, low-effort remediations:

Step 5 - Output Report Format

Produce the following structured report after the analysis. Adapt the verbosity to the requested level.

Report language: write the entire report (titles, descriptions, recommendations, narrative examples) in the language selected in Step 1. If no language was specified, use English by default. Technical identifiers (OWASP category names, CWE IDs, function names, commands) remain in English regardless of the language chosen.

### 📋 OWASP SECURITY AUDIT REPORT

**Date:** [DD/MM/YYYY]
**Scope analyzed:** [short description, e.g.: "Node.js REST API - auth.js and user.controller.js files"]
**Framework reference:** OWASP Top 10 - 2025
**Analysis level:** [Complete / Targeted / Partial (limited context)]
**Execution Context:** [mode=…; service/container=…; cli=…; host_vs_declared_diff=…]

---

#### Executive Summary

[3 to 5 sentences: overall security level, major risks identified, remediation priority.
E.g.: "The analyzed code presents critical vulnerabilities in access control and SQL injection.
Two critical findings require immediate correction before any production deployment.
The overall security level is insufficient for public exposure."]

**Overall risk score:** 🔴 Critical / 🟠 High / 🟡 Moderate / 🟢 Low

---

#### Vulnerability Summary Table

| Severity      | Count |
|---------------|--------|
| 🔴 Critical   | X      |
| 🟠 High       | X      |
| 🟡 Medium     | X      |
| 🟢 Low        | X      |
| ℹ️ Informational | X      |
| **Total**     | **X**  |

---

#### Vulnerability Details by OWASP Category

[Repeat the following block for each category A01 to A10]

---

### [A0X] - [Category Name]

**Status:**
- ✅ Compliant - no vulnerability identified
- ⚠️ Vulnerable - medium or low severity findings
- ❌ Critical - high or critical severity findings
- 🔍 Not assessable - insufficient context (explain why)

#### Findings

[If no vulnerability detected:]
> No vulnerability identified in this category within the analyzed scope.

[For each vulnerability found, use the following block:]

**[OWASP-A0X-NNN]** - [Short, explicit title]

- **Severity:** 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low / ℹ️ Informational
- **Confidence:** 🔵 High / 🟣 Medium / ⚪ Low `[MANUAL VERIFICATION REQUIRED if Low]`
- **Remediation effort:** Low (<1h) / Medium (1-4h) / High (>4h) / Architectural
- **Severity justification:** [Explain in 1 sentence why this level applies, e.g.: "Critical because exploitable without authentication and allows access to the entire database."]
- **Attack surface:** [Specify whether this code is reachable from an untrusted input, e.g.: "Public endpoint POST /api/users, `id` parameter directly injected"]
- **Location:** [file:line / endpoint / component / function, e.g.: `auth.js:47, validateToken() function`]
- **Description:** [Clear explanation of the vulnerability and its mechanism]
- **Potential impact:** [What an attacker can concretely do, e.g.: "Authentication bypass, access to all user accounts"]
- **Proof / Vulnerable example:**
  ```[language]
  // Vulnerable code or configuration (mask any real secret → [SECRET MASKED])
  ```

- **Recommendation:** [Concrete, prioritized, and realistic action]
- **Remediation example:**
  ```[language]
  // Corrected code or secured configuration
  ```
- **References:** [CWE-XXX](https://cwe.mitre.org/data/definitions/XXX.html) | [OWASP - Name](https://owasp.org/...) | CVE-XXXX-XXXXX if applicable

---

#### ⚡ Quick Wins - Fast, High-Impact Gains

[List only Critical or High findings with Low or Medium effort: the priority fixes]

| ID            | Title           | Severity | Effort | Timeline  |
| ------------- | --------------- | -------- | ------ | --------- |
| OWASP-A0X-NNN | [Finding title] | 🔴/🟠    | Low    | Immediate |
| OWASP-A0X-NNN | [Finding title] | 🔴/🟠    | Medium | < 1 week  |

> If there are no Quick Wins: nothing to list, all high-impact fixes require high or architectural effort.

---

#### Prioritized Remediation Plan

[List ordered by urgency, list only actions with findings]

| Priority | Action               | Category | Effort        | Recommended Timeline              |
| -------- | -------------------- | -------- | ------------- | --------------------------------- |
| 1        | 🔴 [Critical action] | A0X      | Low           | Immediate (block deployment)      |
| 2        | 🔴 [Critical action] | A0X      | Architectural | Immediate, redesign plan required |
| 3        | 🟠 [High action]     | A0X      | Medium        | < 1 week                          |
| 4        | 🟡 [Medium action]   | A0X      | High          | < 1 month                         |
| 5        | 🟢 [Low action]      | A0X      | Low           | Next iteration                    |

---

#### Audit Coverage Table

| OWASP Category                                    | Analyzed | Findings count |
| ------------------------------------------------- | -------- | -------------- |
| A01:2025 - Broken Access Control                  | ✅ / ⏭️  | X              |
| A02:2025 - Security Misconfiguration              | ✅ / ⏭️  | X              |
| A03:2025 - Software Supply Chain Failures         | ✅ / ⏭️  | X              |
| A04:2025 - Cryptographic Failures                 | ✅ / ⏭️  | X              |
| A05:2025 - Injection                              | ✅ / ⏭️  | X              |
| A06:2025 - Insecure Design                        | ✅ / ⏭️  | X              |
| A07:2025 - Authentication Failures                | ✅ / ⏭️  | X              |
| A08:2025 - Software or Data Integrity Failures    | ✅ / ⏭️  | X              |
| A09:2025 - Security Logging and Alerting Failures | ✅ / ⏭️  | X              |
| A10:2025 - Mishandling of Exceptional Conditions  | ✅ / ⏭️  | X              |

Legend: ✅ Analyzed | ⏭️ Not analyzed (out of scope or insufficient context)

---

#### Limitations and Excluded Scope

[Explicitly mention what could not be assessed, for example:]

- Infrastructure and server configuration not provided → A05 partially assessed
- Dependency files (package.json, pom.xml, etc.) missing → A03 partially assessable / not assessable for CVE scanning
- Dynamic tests (DAST) not possible in this context → some stored XSS vectors not statically detectable
- Project dockerized but dynamic checks ran on host after user choice → runtime may differ from container (`host_vs_declared_diff=…`)
- Container CLI unavailable / daemon down → runtime checks limited or host-only
- Working directory inside container uncertain → some runtime checks may have used a fallback cwd
- [Other context-specific limitations]

Mandatory Behavior Rules

• The code examples in the reference guides are illustrative: the PHP, Nginx, JavaScript, Node.js, etc. snippets serve only to illustrate the vulnerability pattern, they do not define the scope of the analysis. Systematically transpose each pattern to the language and framework actually used in the audited project
• Never invent vulnerabilities: if the context is insufficient, mark it "Not assessable" with an explanation
• Always justify the severity: each level must be justified in one sentence
• Stay factual and actionable: each finding must have a concrete and realistic recommendation
• Mask detected secrets: never reproduce a token, password, API key, or certificate in plaintext, replace them with [SECRET MASKED] and report their presence as a finding
• Adapt the depth to the context: a 20-line excerpt is not the same as a complete codebase, calibrate the analysis accordingly
• No false positives: distinguish a bad practice (ℹ️ Informational) from an exploitable vulnerability (🟡 to 🔴)
• Consistent numbering: finding IDs follow the format OWASP-A0X-NNN (e.g.: OWASP-A03-001), the NNN numbering restarts at 001 for each category
• CWE references: associate the most precise CWE possible with each finding
• Check the attack surface: before declaring a finding, confirm that the vulnerable code is reachable from an untrusted input (HTTP parameter, cookie, upload, webhook, etc.). A dangerous pattern in unexposed internal code drops by at least one severity level
• Deduplicate cross-category findings: if the same flaw is detectable in several OWASP categories (e.g.: hardcoded secret → A02 + A04), report it in the most relevant category and add a → See also [A0X] mention in the other categories concerned
• [MANUAL VERIFICATION REQUIRED] tag: if the vulnerability is likely but not certain (partially visible code, runtime-dependent behavior, external dependency), keep the finding with ⚪ Low confidence and this tag rather than silently removing it
• Exclude test/dev code from the production scope: a finding in a *.test.*, *.spec.*, __tests__/, fixtures/ file, or one conditioned on NODE_ENV=test, must be noted as ℹ️ Informational or excluded, explicitly state this in "Limitations"
• Resolve Execution Context before runtime commands: complete Step 2 before any npm / node / pip / php / composer / equivalent. Static grep/find on the workspace does not bypass this for runtime tools
• No silent host fallback on dockerized projects: if containers are stopped, ask to start them or to test on the host; if the user picks host, warn on version mismatch and record it in Limitations
• Sub-agents inherit Execution Context: when dispatching category sub-agents, always pass the Execution Context block; reject/ignore runtime commands that omit exec_prefix when mode=docker-exec