devvn-wp-security-audit

Name: devvn-wp-security-audit
Author: levantoan

28stars6forks

How to install devvn-wp-security-audit?

levantoan/devvn-wordpress-skills/devvn-wp-security-audit

$npx -y skills add levantoan/DevVN-WordPress-Skills --skill devvn-wp-security-audit

Installs into the current project.

Summary

Comprehensive WordPress plugin/theme security and code quality audit following WPCS and Plugin Check standards. Scans all PHP files for SQL Injection, XSS, CSRF, Access Control, File Security, Forbidden Functions, Safe Redirect, Input Validation, and Code Quality issues. Reports

Files · 1

View on GitHub

SKILL.md

1	# DevVN WordPress Security & Code Quality Audit
2
3	Performs a full security and code quality audit on WordPress plugins/themes against WPCS (WordPress Coding Standards) and WordPress Plugin Check standards. Covers 8 vulnerability categories with 40+ individual rules, plus code quality and performance checks.
4
5	## When to use
6
7	Activate when:
8	- User asks to "check security", "security audit", "kiểm tra bảo mật", "audit plugin"
9	- User asks to "check code quality", "plugin check", "review code"
10	- Before publishing/releasing a plugin or submitting to WordPress.org
11	- User mentions "devvn-wp-security-audit"
12	- User asks "are there any security vulnerabilities" or "có lỗi bảo mật không"
13	- User asks about SQL injection, XSS, CSRF, nonce, escaping, sanitization
14
15	## Audit process
16
17	### Step 1: Identify scope
18
19	Scan all PHP files in the project:
20	- `src/*/.php` (controllers, services, admin handlers)
21	- `templates/*/.php` (highest XSS risk)
22	- `includes/*/.php` (legacy logic)
23	- `admin/*/.php` (admin views)
24	- Root `*.php` (bootstrap files)
25	- `assets/*/.js` (check data passed from PHP via `wp_localize_script`, `wp_add_inline_script`)
26
27	Priority order: Controllers/Handlers > Templates > Services > Admin views > Bootstrap
28
29	### Step 2: Run security audit
30
31	Use the Agent tool with `subagent_type: feature-dev:code-reviewer`. Pass the complete audit rules from [references/audit-rules.md](references/audit-rules.md) as the prompt.
32
33	Instruct the agent to:
34	- Read ALL files completely before reporting
35	- Report using the exact format from [references/report-format.md](references/report-format.md)
36	- Only report confirmed issues, no false positives
37	- Skip intelephense IDE warnings (undefined function for WP globals is normal)
38	- Report duplicate patterns once, note "same pattern in N files"
39	- Check current code state, not previously fixed issues
40
41	### Step 3: Run code quality audit (if preparing for WordPress.org)
42
43	If the user is preparing for WordPress.org submission or asks for a full audit, also check rules from [references/code-quality-rules.md](references/code-quality-rules.md). This covers:
44	- Prefixing (all globals must have unique prefix)
45	- Setting sanitization (`register_setting()` with `sanitize_callback`)
46	- Performance (enqueued resources, WP_Query params, script loading strategy)
47	- i18n (text domain, translator comments)
48	- Localhost references
49	- Forbidden file types
50	- Plugin headers and uninstall handling
51
52	### Step 4: Report
53
54	Output results in Vietnamese using the format from [references/report-format.md](references/report-format.md). Include:
55	- Each issue with `[TYPE] - [Severity]`, file:line, code snippet, reason, fix
56	- Summary table at the end
57	- "PASS" section listing categories that were audited and found clean
58
59	### Step 5: Fix
60
61	Fix reported issues from Critical to Low, but ask the user before fixing patterns that may be intentional:
62	- SSL verification disabled in cURL fallback (may be needed for hosting compatibility)
63	- Sensitive data passed to frontend JS via `wp_localize_script()` (may be required by frontend logic)
64	- `wp_redirect()` usage (may be intentional for external redirects)
65	- Development functions like `error_log()` (may be needed for debugging)
66	- Other patterns where fixing could break existing functionality
67
68	Only auto-fix issues that are clearly unintentional (missing `esc_html()`, missing `wp_check_filetype()`, raw `unserialize()`, etc.). Run `php -l` on every modified file to verify syntax.
69
70	## Audit categories
71
72	### 1. SQL Injection (SQLi)
73	- `$wpdb->prepare()` required for all queries with user-supplied data
74	- Placeholder count must match parameter count
75	- `$wpdb->esc_like()` required for LIKE clauses
76	- `array_fill` for IN() placeholders, never string concatenation
77	- ORDER BY/GROUP BY must use whitelist validation, never `%s`
78	- Prefer WP abstraction (`get_posts`, `WP_Query`) over direct `$wpdb` when possible
79
80	### 2. Cross-Site Scripting (XSS)
81	- All `$_GET`/`$_POST`/`$_REQUEST` must be sanitized on input
82	- All output must be escaped late (right before echo): `esc_html()`, `esc_attr()`, `esc_url()`, `esc_textarea()`
83	- Flag any `echo`/`print`/`printf` of variables without `esc_*` functions
84	- Even numeric DB values must be cast `(i

People who liked this also viewed

6 picks

Type

devvn-wp-security-audit

28stars6forks

View on GitHub

How to install devvn-wp-security-audit?

levantoan/devvn-wordpress-skills/devvn-wp-security-audit

$npx -y skills add levantoan/DevVN-WordPress-Skills --skill devvn-wp-security-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# DevVN WordPress Security & Code Quality Audit
2
3	Performs a full security and code quality audit on WordPress plugins/themes against WPCS (WordPress Coding Standards) and WordPress Plugin Check standards. Covers 8 vulnerability categories with 40+ individual rules, plus code quality and performance checks.
4
5	## When to use
6
7	Activate when:
8	- User asks to "check security", "security audit", "kiểm tra bảo mật", "audit plugin"
9	- User asks to "check code quality", "plugin check", "review code"
10	- Before publishing/releasing a plugin or submitting to WordPress.org
11	- User mentions "devvn-wp-security-audit"
12	- User asks "are there any security vulnerabilities" or "có lỗi bảo mật không"
13	- User asks about SQL injection, XSS, CSRF, nonce, escaping, sanitization
14
15	## Audit process
16
17	### Step 1: Identify scope
18
19	Scan all PHP files in the project:
20	- `src/*/.php` (controllers, services, admin handlers)
21	- `templates/*/.php` (highest XSS risk)
22	- `includes/*/.php` (legacy logic)
23	- `admin/*/.php` (admin views)
24	- Root `*.php` (bootstrap files)
25	- `assets/*/.js` (check data passed from PHP via `wp_localize_script`, `wp_add_inline_script`)
26
27	Priority order: Controllers/Handlers > Templates > Services > Admin views > Bootstrap
28
29	### Step 2: Run security audit
30
31	Use the Agent tool with `subagent_type: feature-dev:code-reviewer`. Pass the complete audit rules from [references/audit-rules.md](references/audit-rules.md) as the prompt.
32
33	Instruct the agent to:
34	- Read ALL files completely before reporting
35	- Report using the exact format from [references/report-format.md](references/report-format.md)
36	- Only report confirmed issues, no false positives
37	- Skip intelephense IDE warnings (undefined function for WP globals is normal)
38	- Report duplicate patterns once, note "same pattern in N files"
39	- Check current code state, not previously fixed issues
40
41	### Step 3: Run code quality audit (if preparing for WordPress.org)
42
43	If the user is preparing for WordPress.org submission or asks for a full audit, also check rules from [references/code-quality-rules.md](references/code-quality-rules.md). This covers:
44	- Prefixing (all globals must have unique prefix)
45	- Setting sanitization (`register_setting()` with `sanitize_callback`)
46	- Performance (enqueued resources, WP_Query params, script loading strategy)
47	- i18n (text domain, translator comments)
48	- Localhost references
49	- Forbidden file types
50	- Plugin headers and uninstall handling
51
52	### Step 4: Report
53
54	Output results in Vietnamese using the format from [references/report-format.md](references/report-format.md). Include:
55	- Each issue with `[TYPE] - [Severity]`, file:line, code snippet, reason, fix
56	- Summary table at the end
57	- "PASS" section listing categories that were audited and found clean
58
59	### Step 5: Fix
60
61	Fix reported issues from Critical to Low, but ask the user before fixing patterns that may be intentional:
62	- SSL verification disabled in cURL fallback (may be needed for hosting compatibility)
63	- Sensitive data passed to frontend JS via `wp_localize_script()` (may be required by frontend logic)
64	- `wp_redirect()` usage (may be intentional for external redirects)
65	- Development functions like `error_log()` (may be needed for debugging)
66	- Other patterns where fixing could break existing functionality
67
68	Only auto-fix issues that are clearly unintentional (missing `esc_html()`, missing `wp_check_filetype()`, raw `unserialize()`, etc.). Run `php -l` on every modified file to verify syntax.
69
70	## Audit categories
71
72	### 1. SQL Injection (SQLi)
73	- `$wpdb->prepare()` required for all queries with user-supplied data
74	- Placeholder count must match parameter count
75	- `$wpdb->esc_like()` required for LIKE clauses
76	- `array_fill` for IN() placeholders, never string concatenation
77	- ORDER BY/GROUP BY must use whitelist validation, never `%s`
78	- Prefer WP abstraction (`get_posts`, `WP_Query`) over direct `$wpdb` when possible
79
80	### 2. Cross-Site Scripting (XSS)
81	- All `$_GET`/`$_POST`/`$_REQUEST` must be sanitized on input
82	- All output must be escaped late (right before echo): `esc_html()`, `esc_attr()`, `esc_url()`, `esc_textarea()`
83	- Flag any `echo`/`print`/`printf` of variables without `esc_*` functions
84	- Even numeric DB values must be cast `(i

People who liked this also viewed

6 picks

Type