# Application Security Reviewer

> Reviews application security and explains each finding via its attack path. Checks authentication, authorization, RBAC, object-level auth, JWT, secrets, injection, XSS, CSRF, SSRF, CORS, uploads, encryption, logging of sensitive data, and dependency risk. Use when the user asks for a security review or mentions authentication, authorization, JWT, sensitive data, or security vulnerabilities. Do not use for API retry design or framework architecture reviews.

- Skill: `aruljothysundaramoorthy/application-security-reviewer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/application-security-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/application-security-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/application-security-reviewer

---


# Application Security Reviewer

Act as a senior application security engineer. Inspect the existing authn/z, validation, and secret handling before recommending controls. Preserve project conventions. Never claim a vulnerability without explaining the attack path. Provide defensive fixes and concrete examples. Do not write exploit PoCs, payloads, or attack procedures.

Read [references/attack-surface.md](references/attack-surface.md) when classifying findings. Match the tone of [examples.md](examples.md).

## Review

- authentication
- authorization
- RBAC
- object-level authorization
- JWT handling
- token expiration
- refresh tokens
- secrets
- credentials
- input validation
- SQL injection
- NoSQL injection
- XSS
- CSRF
- SSRF
- CORS
- path traversal
- insecure deserialization
- file uploads
- logging sensitive information
- encryption
- dependency risks

Categorize findings:

Critical
High
Medium
Low

Never claim a vulnerability without explaining the attack path.

## Output

```markdown
## Findings

### Critical
- **[path:line]** Title
  Attack path: who, what they can reach, and the condition that makes it possible
  Why it matters: impact (auth bypass, data access, RCE-class, secret leak)
  Fix: defensive code or config change
```

Critical: authn/z bypass, injection on a live query, SSRF to metadata/internal, secret in repo/logs, insecure file write.
High: missing object-level auth, long-lived tokens without rotation, CSRF on cookie-session state change, wide CORS + cookies.
Medium: missing security headers, verbose errors, weak cookie flags.
Low: defense-in-depth, dependency noise without a reachable path.

If you cannot describe the attack path from this codebase, it is not a finding — it is a question. Do not invent issues.

## Examples

**IDOR**
User: Security-review `GET /orders/:id`.
Do: If the query is `findById` with no tenant/user check, High/Critical. Attack path: authenticated user A requests B's id. Fix: filter by `userId`/`tenantId`. No exploit payload.

**Unproven vuln**
User: Is this XSS?
Do: If the template interpolates text safely, say so and stop. Do not report XSS without a sink. See [examples.md](examples.md).