Security review

When to use it

Use this skill to audit a plugin, theme, REST route or AJAX handler, or to judge whether a suspected exploit is real. It looks for missing capability or ownership checks, XSS, SQL injection, CSRF, SSRF, unsafe uploads, exposed secrets, dependency risk and multisite isolation problems.

Designing REST routes belongs to the REST skill. This skill stays with the exploit path itself.

What it hands off

• REST route and schema design goes to wp-devkit-rest-api-development.
• WooCommerce payment or order flows go to wp-devkit-woocommerce-dev.
• CI gate wiring goes to wp-devkit-ci-cd-and-release-engineering.
• Hosting and WP-CLI operations go to wp-devkit-wpcli-and-ops.

Run a review in Claude

With the plugin loaded, start a read-only review of one bounded target:

/wp-devkit:security-review <target-path>

The shorter /wp-devkit:security asks for a quick scan instead.

Run a review in Codex, ChatGPT or Antigravity

Name the installed skill and keep the request small. Replace the target with your own files or journey.

$wp-devkit-security-review
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

The engineering contract is the set of rules every DevKit skill follows. It covers how findings are rated and what counts as evidence.

How a review works

1. The agent lists every entry point: admin-ajax and admin_post_* actions (including nopriv), REST routes, shortcodes, block render callbacks, form, init and template_redirect handlers, cron and WP-CLI callbacks, uploads, webhooks, and unserialize of stored data.
2. For each one, it records who can call it, what they control, and which sink they reach. A sink is the place where input does its damage, such as SQL, HTML or URL output, the filesystem, an outbound request, an include or exec call, or an option or capability write.
3. It walks from source to sink and notes each control on the path: login, capability or object ownership, a nonce that proves intent, validation, parameterization, escaping for the output context, and a destination allowlist. Core helpers and shared wrappers count, so the agent reads them.
4. A control is missing only when no layer on the reachable path provides it. Public-by-design behavior is not a defect. Abusing it is one, but only when limits are absent and the impact is shown.
5. It runs the false-positive checks in security-review-workbook.md. Severity follows the demonstrated impact, and requiring a login does not lower it by itself.
6. It proposes the fix at the failing boundary, plus a regression test with three actors: the authorized owner, a logged-in user who is the wrong owner, and an anonymous visitor. It does not implement the fix during the review.

Reference files

The agent starts with the workbook, then loads only the files that match the question:

• security-review-workbook.md is read first. It covers severity calibration, the finding template, a catalogue of harmless look-alikes and the acceptance checks.
• access-control-and-csrf.md is used for any authorization or CSRF question. It covers capability and object checks, REST, AJAX and admin-post handlers, nonces, application passwords, role and privilege writes, and multisite capabilities.
• input-output-and-sql.md is used for XSS, SQL injection or object injection. It covers validation versus sanitization, wp_unslash, $wpdb->prepare including %i, LIKE and IN, escaping by context, DOM sinks and serialization.
• files-network-and-execution.md is used when the path touches files, outbound requests or code execution. It covers uploads, path traversal, archives, SSRF, redirects and include or exec.
• abuse-multisite-concurrency.md is used for abuse, replay, quota or cross-site questions. It covers public endpoints, brute force, webhooks, tenant isolation and race conditions.
• dependency-supply-chain.md is used when dependencies or the build chain are in scope. It covers Composer and npm audits, provenance and CI actions.
• runtime-hardening.md is used when the deployed configuration is in scope. It covers headers, cookies, debug settings, file policy and the limits of dynamic testing.
• secrets-and-integrity.md is used for exposed credentials, tampering or privacy exposure. It covers secret scanning, rotation, checksums, CSP rollout and personal data in logs.

What you get back

The report opens with the verdict and the scope it covered. Each confirmed finding follows the workbook template: severity, file and line, actor, trigger, the path from source to sink, impact, confidence, a minimal fix and a regression test. Candidates and missing evidence come in a separate list.

The report ends with the checks that ran (command and exit status), the checks that did not run, and the risk that remains. An implementation also lists the boundaries it changed and the regression result before and after the fix. "No findings" means nothing was found in the inspected scope. It does not mean the system is secure.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.