Avoid sanitization false positives for password, token, and API key fields

[davidperezgar]

Summary

The WordPress.Security.ValidatedSanitizedInput check (used by Plugin Check to detect unsanitized input) flags any access to superglobals ($_POST, $_GET, $_REQUEST, etc.) that doesn't go through a sanitization function, including cases where the array key corresponds to a password field (e.g. $_POST['password']).

However, sanitizing a password before comparing or storing it (with wp_hash_password(), wp_check_password(), etc.) can alter its actual value, since a password can legitimately contain any combination of characters. Applying sanitize_text_field() or other sanitization functions to this kind of value can:

• Strip valid characters from the password (spaces, quotes, symbols, etc.), breaking login or credential registration for users whose password contains those characters.
• Trigger a false "insecure field" alarm when the data is actually being handled correctly (it's only stored as a hash or compared, never displayed or used in an unprepared query).

Our internal review tool already treats this as a known false positive, showing the following note to the reviewer/plugin author:

Note - as long it's only saved and compared when needed, better to not sanitize a password

And the internal documentation for the check expands on the criteria:

Passwords, some tokens, signatures are not eligible to be sanitized as long they are used safely. This is because it's their nature to be a conjunction of any character and sanitizing them can change them. The same can happen to API Keys and similar depending on the case.

Proposal

Apply an equivalent criterion in Plugin Check (WordPress.Security.ValidatedSanitizedInput and/or the AI analysis in ai-review-sanitization.md) so that:

1. When a superglobal array key contains terms such as password, pwd, pass, token, secret, signature, api_key (or similar), and the value is only used for comparison (wp_check_password(), hash_equals(), direct comparison) or to generate a hash before storing it, the severity is lowered or an informational note is shown instead of a "not sanitized" error.
2. This case is documented in docs/checks.md and/or in the AI prompt prompts/ai-review-sanitization.md, so the AI analysis doesn't flag these cases as a sanitization false negative.

Additional context

• Internal tool reference: class-parser_sanitize.php (property $common_false_positives_input_keys) and ai_check_sanitize.md.
• Real-world example flagged by our internal tool:

  includes/Auth.php:261 $password = isset( $_POST['password'] ) ? wp_unslash( $_POST['password'] ) : '';
       -----> $_POST['password']
       # Note: as long it's only saved and compared when needed, better to not sanitize a password
  

---

Disclaimer: This issue was drafted with the help of an AI (Claude) based on a review of the code and documentation of our internal review tool.