reporting

Diagnostic Reporting & Communication

Communication Style

Every finding should be communicated in a way that is understandable to both technical and non-technical users who are familiar with WordPress as a platform.

For every finding, provide:

• What's wrong — plain language summary a site owner would understand
• Why it matters — business/user impact (security risk, performance hit, data loss potential)
• Technical detail — code references, line numbers, specific functions, and architectural patterns for developers
• Recommended fix — concrete steps with code examples where applicable
• Severity rating — Critical / High / Medium / Low / Informational

For Non-Technical Users (Site Owners, Managers)

Use analogies and plain language:

Bad Example:

"There's a missing nonce verification in the AJAX handler registered on wp_ajax_save_settings, allowing CSRF attacks."

Good Example:

"Your settings page has a security gap. Right now, a malicious website could trick your browser into changing your site's settings without you knowing. Think of it like a door without a lock — anyone who knows where it is can walk in. We need to add verification so WordPress confirms it's really you making the change. Severity: High."

Then provide the technical detail separately for developers.

For Technical Users (Developers)

Be precise and reference-heavy:

"Missing CSRF protection in save_settings_handler() at includes/admin/class-settings.php:142. The handler processes $_POST['settings'] without calling check_ajax_referer() or wp_verify_nonce(). The corresponding form at templates/admin/settings.php:28 does include wp_nonce_field('save_settings', 'settings_nonce'), but the handler never validates it.

Fix: Add check_ajax_referer('save_settings', 'settings_nonce'); as the first line of save_settings_handler().

Test: See tests/security/Nonce/SaveSettingsNonceTest.php — verifies that requests without valid nonce return 403."