Sanitization, escaping, and capability requirements

POM helpers do not replace WordPress security controls. Treat every request value, builder attribute, setting, metadata value, and merge-tag attribute according to its source and final context.

State-changing requests

A write handler must:

1. require an appropriate WordPress capability;
2. verify a nonce or authenticated REST permission;
3. validate identifiers against the resource being changed;
4. sanitize each accepted value;
5. reject unsupported keys;
6. return a user-safe error.

A nonce proves request intent, not authorization. Check both.

For REST routes, provide a real permission_callback and argument schemas. For AJAX or form handlers, do not trust a submitted user ID, post ID, recipient, or role without resolving it server-side.

Escape at the destination

• use esc_html() for text nodes;
• use esc_attr() for attributes;
• use esc_url() for URLs;
• use wp_kses_post() only for intentionally supported post HTML;
• use wp_json_encode() or WordPress JSON responses for structured data.

Do not escape values before storage as a substitute for output escaping. Trusted POM renderer functions may return complete markup; sanitize the inputs passed to them and do not turn that markup into plain text with esc_html().

Authorization boundaries

Permission rules control whether POM presents content. They do not grant administrative capabilities, order access, private-post access, or REST authorization.

CSS visibility, hidden inputs, builder controls, and JavaScript checks are never access controls.

Sensitive data

Do not log form contents, customer details, license keys, nonces, signed descriptors, or authentication headers. Keep public error messages free of paths, query text, stack traces, and storage details.

Verification

Test the valid request, missing capability, missing or invalid nonce, altered object ID, unexpected field, malformed value, and direct request while signed out.