application-security-review

Application Security Review

Perform a practical source-level security review of an application repository. Favor confirmed issues over speculative ones. The goal is a useful operator-facing report: severity, file/line references, exploit path, impact, and remediation.

Use when

• The user asks to "scan for security issues", "review for security", or "audit this repo/app".
• The user asks whether a native app or realtime AI/voice prototype is ready to sell, ship, distribute, or submit to an app store.
• Reviewing AI-integrated apps, browser/UIs, add-ins, extensions, native mobile apps, or local proxies.
• Evaluating whether a prototype is safe for local-only use vs real deployment.

For native iOS commercial-readiness reviews, load and follow the readiness checklist. It expands the audit beyond security into StoreKit, App Store compliance, realtime audio reliability, consumer UX, unit economics, and release gates.

Review priorities

1. Trust boundaries first.

• What input is untrusted?
• What backend capabilities sit behind the UI?
• Can model output or user-controlled content trigger side effects?

1. Auth and exposure.

• Localhost services, reverse proxies, injected auth headers, CORS, TLS, origin restrictions.

1. Validation before execution.

• JSON/action parsing, schema checks, range/size limits, before/after verification, allowlists.

1. Data handling.

• What leaves the machine, what is logged, whether sensitive user data is silently sent to cloud backends.
• For public-release reviews, scan both tracked source and git metadata for PII: local hostnames, personal emails, profile names, private org/business names, absolute user paths, and secret/token patterns.

1. Dependencies.

• Separate runtime risk from dev-toolchain risk.

Workflow

1. Read top-level README and manifests/config first to understand architecture.
2. Locate network entry points and auth flow.
3. Trace untrusted input to powerful sinks:

• LLM prompts
• filesystem/terminal/network tools
• code execution
• document/workbook mutations

1. Search for:

• fetch/XHR/API calls
• proxies and bearer-token injection
• JSON.parse on model output
• eval/Function/innerHTML/dangerous DOM sinks
• wildcard CORS or broad allowlists
• dependency versions with known advisories

1. For public-release/privacy scans, include repository metadata and the actual remote publication surface as well as source:

• Before first push, inspect staged/tracked files, local author metadata, and reachable history to catch accidental local-hostname identities and workstation paths.
• Scan tracked/source files for emails, hostnames, <user-home>/..., C:\\Users\\<name>, private profile names, internal org names, token prefixes, and generated run artifacts.
• After push or history rewrite, make the publication verdict from a fresh remote clone/mirror, every public branch/tag and PR ref, PR text, commit metadata, and all reachable blobs. Do not count ignored files, virtual environments, local reflogs, or stale remote-tracking refs as currently published content.
• Use an independent-model review when practical, then verify findings yourself; classifiers often mislabel loopback, placeholder paths, or code symbols as PII.
• Confirm the update reaches the intended default/publication branch rather than remaining only on a feature branch.
• Distinguish generic loopback (127.0.0.1), contextual test IPs, GitHub noreply identities, placeholder fixtures, and code symbols ending in .local from real PII or private-machine identifiers.