security

name

security

description

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.

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
Login, sessions, tokens, roles, ownership, tenancy, privilege	access-control.md
XSS, SQL, command, template injection, CSRF, SSRF, deserialization	injection.md
Uploads, cryptography, personal data, logging, retention	data-protection.md
WordPress, WooCommerce, plugins, themes, wp-admin	wordpress.md
Dependencies, CI/CD, secrets, headers, cloud and infrastructure	supply-chain.md
Writing findings, severity, proof of concept, verification	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