Sanitization Pipelines: Mastering WordPress Input Validation

Previously in this course, we explored the Data Access Objects Pattern to handle our database interactions. While that layer ensures we use prepared statements, it assumes the data reaching it is already "clean." This lesson introduces the Sanitization Pipeline, a mandatory architectural boundary that sits between your request handlers and your data access layer to ensure only validated, sanitized data enters your system.

The Problem with "Just Sanitize"

Most developers treat sanitization as an afterthought—calling sanitize_text_field() somewhere deep inside a model or repository. This is an anti-pattern. If you wait until the data reaches the database layer, you've already allowed "dirty" data to propagate through your service providers and business logic.

A proper Sanitization Pipeline follows the principle of "Validate at the edge, sanitize at the sink." By defining an input schema at the controller level, you guarantee that your internal services only ever process predictable, well-formed data.

Defining the Validation Layer

In our Knowledge Base plugin, we want to ensure that every POST request to our custom endpoints undergoes a strict check. We will define an interface for our validators, allowing us to enforce schemas consistently across the application.

PHP
interface InputValidatorInterface {
    public function validate(array $data): array;
}

By using this interface, we can inject specific validators into our controllers, keeping our request handling clean and testable.

Worked Example: A Strict Sanitization Pipeline

Let's implement a KnowledgeBaseEntryValidator that handles the creation of a new knowledge base article. We'll use WordPress core functions to enforce types and lengths before the data ever hits our EntryRepository.

PHP
namespace KnowledgeBase\Validation;

class EntryValidator implements InputValidatorInterface {
    public function validate(array $data): array {
        $validated = [];

        #6A9955">// 1. Strict Type Validation
        if (empty($data['title']) || !is_string($data['title'])) {
            throw new \InvalidArgumentException('Title is required and must be a string.');
        }

        #6A9955">// 2. Sanitization
        $validated['title'] = sanitize_text_field($data['title']);
        
        #6A9955">// 3. Schema Enforcement
        $validated['category_id'] = isset($data['category_id']) ? absint($data['category_id']) : 0;
        
        #6A9955">// 4. Content Sanitization(using wp_kses_post for HTML content)
        $validated['content'] = isset($data['content']) ? wp_kses_post($data['content']) : '';

        return $validated;
    }
}

In your controller, you now have a single, predictable point of entry:

PHP
public function store(WP_REST_Request $request) {
    try {
        $data = $this->validator->validate($request->get_params());
        return $this->repository->create($data);
    } catch (\InvalidArgumentException $e) {
        return new WP_Error('invalid_input', $e->getMessage(), ['status' => 400]);
    }
}

Hands-on Exercise

1. Create a Validator: Implement an InputValidatorInterface for a new "Settings" update feature in your plugin.
2. Define Rules: Ensure that a user_email field is passed through sanitize_email() and is_email().
3. Throw Exceptions: If the email is invalid, throw an InvalidArgumentException.
4. Integrate: Inject this new validator into your settings controller and ensure it intercepts the request before calling your data update service.

Common Pitfalls

• Sanitizing too early: Never sanitize data before it reaches your validation layer. You need the raw input to check against your schema requirements (e.g., checking if a required field is missing).
• Assuming sanitize_text_field is magic: It strips tags and removes newlines, but it doesn't validate business logic. It won't tell you if a user provided a valid ID or a properly formatted date.
• Over-sanitizing: Avoid using sanitize_text_field on data that requires specific formatting (like serialized JSON or complex HTML). Use contextual functions like wp_kses_post or absint instead.
• Ignoring wp_unslash: Remember that $_POST data in WordPress is slashed by default. When building APIs, use the WP_REST_Request object, which handles unslashing for you automatically.

Summary

By implementing a dedicated validation layer, you shift security from a reactive "patch" to a proactive architectural requirement. Your services become more robust because they can trust the data they receive, and your controllers become readable, focused handlers of the HTTP lifecycle.

Up next: Output Escaping Patterns, where we ensure that the data we just sanitized is safely rendered back to the user.