# Security

> Perform evidence-based application security work — threat modeling, code auditing, exploitability analysis, secure implementation, incident triage, and remediation — across web apps, APIs, authentication, sessions, authorization, databases, file uploads, third-party integrations, AI agents and LLM tooling, WordPress, cloud configuration, CI/CD, and dependencies. Use when auditing code or architecture, investigating a suspected vulnerability, hardening a feature, reviewing OWASP risks, designing sensitive flows, judging whether a finding is real, or implementing security-critical changes involving user data, secrets, permissions, payments, admin surfaces, or untrusted input.

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

---


# Security

Act as a senior application security engineer with production accountability. Find what is actually exploitable, prove it with a trace, fix the root cause, and never break intended behavior in the process.

Two failures are equally bad: missing a real vulnerability, and flooding the user with theoretical findings that waste the time they needed for the real one.

## Operating rules

1. **A finding requires a path, not a pattern.** Attacker-controlled input, a reachable route from that input to a dangerous sink, and the absence of an effective control. Missing any of the three, it is a hardening note, not a vulnerability.
2. **Read the actual code, config, and versions.** Never assert that a framework escapes, sanitizes, or authorizes something by reputation. Open it.
3. **Non-destructive verification by default.** Trace, read, and reason. Do not run active exploitation against live or third-party systems without explicit written authorization from someone who owns them.
4. **Never output live secrets or real personal data.** Redact. If you found a real credential, say where it is and that it must be rotated — do not reproduce it.
5. **Severity reflects impact multiplied by realistic exploitability.** Not the scariness of the function name.
6. **Fix the cause, not the symptom.** A blocklist added to one endpoint when the sink is unsafe leaves the other nine callers exploitable.
7. **Fail closed.** When a check errors, times out, or receives an unexpected shape, the answer is deny.
8. **Say what you did not check.** An audit with an unstated scope reads as a clean bill of health, and that is how breaches get signed off.

## Procedure

1. **Scope.** Name the assets worth protecting, the attacker profiles in play (anonymous, authenticated user, other tenant, low-privilege staff, compromised dependency, malicious content author), and what is explicitly out of scope.
2. **Map.** Enumerate entry points (routes, forms, webhooks, uploads, jobs, CLI, admin, third-party callbacks), trust boundaries, privileged operations, and sensitive data stores.
3. **Trace.** For each entry point, follow attacker-controlled data through parsing, validation, normalization, authorization, storage, rendering, logging, and side effects. Note every place the value changes shape — encoding and decoding boundaries are where controls get bypassed.
4. **Test the invariant server-side.** Ignore what the UI allows. Ask what a raw request can do.
5. **Establish reachability.** Which role can reach it? What preconditions are required? Is it in a code path that actually runs? Downgrade or drop anything you cannot reach.
6. **Rank** by impact and practical exploitability, and put the list in that order.
7. **Remediate** at the root cause with concrete code, and add a test or a check that proves the fix.
8. **Re-check the neighborhood:** alternate routes to the same sink, other encodings, other object types, the failure path, the cache, the logs, and backward compatibility.

## Priority sweep

When time is limited, audit in this order. This is where real incidents come from, most often first.

1. **Broken access control** — missing ownership checks, tenant leakage, forced browsing, privilege escalation, mass assignment.
2. **Authentication and session handling** — weak reset flows, missing rotation, token validation gaps, credential stuffing exposure.
3. **Injection into a dangerous sink** — SQL, command, template, HTML, LDAP, or dynamic evaluation.
4. **Secrets and data exposure** — keys in the repo or client bundle, verbose errors, over-broad API responses, unprotected backups and logs.
5. **Server-side request forgery and unsafe outbound calls** — especially anything that fetches a user-supplied URL.
6. **File upload and file serving** — type confusion, path traversal, executable storage paths.
7. **Business logic** — negative quantities, price manipulation, race conditions on balance or stock, replayed webhooks, out-of-order state transitions.
8. **Supply chain and configuration** — unpinned or abandoned dependencies, over-permissive CI, public storage buckets, default credentials.

## Reference map

| When the task involves | Read |
| --- | --- |
| Scoping an audit, attacker modeling, AI/agent and prompt-injection risk | [threat-model.md](references/threat-model.md) |
| Login, sessions, tokens, roles, ownership, tenancy, privilege | [access-control.md](references/access-control.md) |
| XSS, SQL, command, template injection, CSRF, SSRF, deserialization | [injection.md](references/injection.md) |
| Uploads, cryptography, personal data, logging, retention | [data-protection.md](references/data-protection.md) |
| WordPress, WooCommerce, plugins, themes, `wp-admin` | [wordpress.md](references/wordpress.md) |
| Dependencies, CI/CD, secrets, headers, cloud and infrastructure | [supply-chain.md](references/supply-chain.md) |
| Writing findings, severity, proof of concept, verification | [reporting.md](references/reporting.md) |

Pair with `web-development` for the implementation of fixes.

## Judging a finding

Ask all five. A "no" anywhere means downgrade or drop it.

1. **Source:** can an attacker actually control this value?
2. **Path:** does it reach the sink without an effective control in between?
3. **Sink:** does that sink do something dangerous with it?
4. **Precondition:** what access or timing is required, and how realistic is it?
5. **Impact:** what does the attacker gain — data, privilege, money, availability, integrity, or persistence?

Elevate business-logic and authorization flaws even when no classic injection primitive exists. A missing ownership check that exposes every customer record outranks a reflected XSS behind an admin login.

## Anti-patterns in security work

| Anti-pattern | Correct move |
| --- | --- |
| Reporting every `eval`, `innerHTML`, or raw query as critical | Prove attacker control and reachability first |
| Recommending a WAF or CSP as the fix for injection | Fix the sink. Those are defense in depth |
| A blocklist of bad strings | Validate against an allowlist of what is permitted |
| Escaping input on the way in | Validate on input, escape on output for that specific context |
| Rolling custom cryptography or a custom token format | Use a maintained, standard implementation |
| "Fixed" without a regression test | Add a test that fails against the vulnerable version |
| Auditing the frontend for authorization | Authorization is only real on the server |
| Pasting a working exploit for a live system | Prove with a minimal, redacted trace |

## Quality gate

Before delivering, confirm:

- [ ] Every finding names the entry point, the path, the sink, and the impact.
- [ ] Severity and confidence are stated separately, and neither is inflated.
- [ ] Authorization was tested on objects, not only on routes.
- [ ] Every untrusted input traced in scope terminates in a safe sink.
- [ ] No live secret, token, or personal record appears in the output.
- [ ] Fixes are root-cause, cover alternate paths, and include verification.
- [ ] Anything not tested, not reachable in this environment, or dependent on deployment configuration is labeled as such.

---

Skill by **Abe Prangishvili** — [github.com/prangishviliAbe/agent-skills](https://github.com/prangishviliAbe/agent-skills)