Security And Capability Checks

This page intentionally describes the plugin's security model at a high level only. Capability identifiers, nonce action names, the implementation of secret storage, signing of unattended requests and other security-relevant internals are not published here.

Security model at a glance

• Capability-gated admin. Plugin administration is restricted to users with the appropriate WordPress capability. Granting that capability is managed through the WordPress role system.
• Request authenticity. Privileged admin operations (forms and admin-AJAX endpoints) verify a per-action nonce before doing any work.
• Unattended automation. When the plugin exposes a callable endpoint for external schedulers, it is protected by a server-side secret managed from the plugin's admin UI; the secret is never echoed back into the page.
• Standard WordPress safeguards. All input is sanitised and all output is escaped using the appropriate WordPress APIs.

For supported sanitisation conventions used inside the plugin's own code, see Sanitization And Escaping.

Operating guidance

• Grant plugin-management capability only to roles that genuinely need it.
• Treat any secret entered into the plugin (API credentials, automation token, webhook secret) as a credential. Restrict database access on production hosts and avoid exporting these values in unencrypted backups.
• Rotate the automation token if it may have been disclosed.
• Keep WordPress, PHP and the plugin itself up to date.

Supported public integration surfaces

When integrating with the plugin, prefer these stable surfaces:

• The plugin admin settings UI.
• The documented shortcodes.
• Theme-level template overrides as described in Template System And Overrides.
• The general Developer Overview for orientation.

Internal class names, option keys, database tables, REST and AJAX endpoints, cron hook names, capability and nonce identifiers, and release / update infrastructure are treated as implementation details. They may change between releases without notice and are not part of the public integration contract.

Stability and change policy

Anything not listed as a supported public surface above is considered an internal implementation detail. Internal APIs, storage layout and security implementation may change between releases. Do not depend on them from third-party code, themes or external systems. Direct database writes are not supported.

Public documentation notice. This page provides a high-level integration overview only. Internal implementation details, private APIs, storage internals and security-sensitive release infrastructure are maintained separately and are not part of the public documentation. Supported integration surfaces are the documented shortcodes, template overrides, settings UI and any extension points explicitly published in this section.