WordPress DevKitTHE FIELD GUIDE

Home / Guides

WordPress DevKit / Field guide

Security review

Review or remediate reachable WordPress security defects.

When to use it

Review or remediate reachable WordPress security defects: missing capability or ownership checks, XSS, SQL injection, CSRF, SSRF, unsafe uploads, secrets, dependency risk, multisite isolation. Use for plugin/theme/REST/AJAX audits and exploit-path triage; route design belongs to the REST skill.

Boundaries and hand-offs

REST route and schema design to wp-devkit-rest-api-development; WooCommerce payment or order flows to wp-devkit-woocommerce-dev; CI gate wiring to wp-devkit-ci-cd-and-release-engineering; hosting and WP-CLI operations to wp-devkit-wpcli-and-ops. Stay here for the exploit path itself.

Ask Claude

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

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

The short form /wp-devkit:security requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your 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.

What it covers

The agent loads only the reference that matches the task:

  • abuse-multisite-concurrency.md: public endpoints, brute force, webhooks, tenant isolation, races. Read for abuse, replay, quota or cross-site questions.
  • access-control-and-csrf.md: capability and object checks, REST/AJAX/admin-post, nonces, application passwords, role and privilege writes, multisite capabilities. Read for any authorization or CSRF question.
  • dependency-supply-chain.md: Composer/npm audits, provenance, CI actions. Read for dependency or build-chain scope.
  • files-network-and-execution.md: uploads, path traversal, archives, SSRF and redirects, include/exec. Read when the path touches files, outbound requests or code execution.
  • input-output-and-sql.md: validation vs sanitization, wp_unslash, $wpdb->prepare including %i and LIKE/IN, escaping by context, DOM sinks, serialization. Read for XSS, SQL injection or object injection.
  • runtime-hardening.md: deployed headers, cookies, debug, file policy, DAST bounds. Read when deployed configuration is in scope.
  • secrets-and-integrity.md: secret scanning, rotation, checksums, CSP rollout, personal data in logs. Read for exposed credentials, tampering or privacy exposure.
  • security-review-workbook.md: Security review workbook

How a review runs

  1. Enumerate entrypoints: admin-ajax and admin_post_* actions (including nopriv), REST routes, shortcodes, block render callbacks, form/init/template_redirect handlers, cron and WP-CLI callbacks, uploads, webhooks, unserialize of stored data.
  2. For each, record who can call it, what they control, and which sink they reach (SQL, HTML/JS/URL output, filesystem, outbound request, include/exec, option or capability write).
  3. Walk source to sink and note each control actually on the path: authentication, capability or object ownership, intent (nonce), validation, parameterization, context escaping, destination allowlist. Core helpers and shared wrappers count; read them.
  4. A control is missing only if no layer on the reachable path provides it. Public-by-design behavior is not a defect; abuse of it is, if bounded limits are absent and impact is shown.
  5. Run the false-positive checks in references/security-review-workbook.md. Classify per the contract: demonstrated impact sets severity, authentication alone does not downgrade it.
  6. Propose the fix at the failing boundary and a regression that uses three actors: authorized owner, authenticated wrong owner, anonymous. Do not implement it during review. Read references/security-review-workbook.md for severity calibration, the finding template, false-positive catalogue and acceptance checks. Then load only the topic references below.

What you get back

Lead with the verdict and reviewed scope. Per confirmed finding use the template in the workbook: severity, file:line, actor, trigger, path source to sink, impact, confidence, minimal fix, regression. List candidates and missing evidence separately. End with executed checks (command, exit status), unexecuted checks and residual risk. For implementation add changed boundaries and the before/after regression result. "No findings" means none in the inspected scope, not that 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.

← All guidesYour first review →