Security and Permissions

Capability Requirements #

The plugin uses different capability checks depending on which part of the product is being accessed.

Settings and Log Access #

The settings page and log-viewing surfaces require manage_options. The loaded installation, admin-operations, and troubleshooting documentation all confirm that the settings menu, settings page, standalone log viewer, log AJAX handlers, and log REST permissions are administrator-level surfaces guarded by manage_options.

This applies to:

  • the top-level Davix H2I settings page
  • the hidden log viewer page
  • AJAX log refresh and fetch actions
  • log REST routes
  • the standalone admin-post log viewer path

Media Workflow Access #

The feature REST routes used by Image, H2I, and Tools require upload_files, after the nonce check passes. The loaded docs describe this shared permission callback as davix_h2i_rest_permissions().

This applies to the feature endpoints for:

  • Image preview and generate
  • H2I preview and generate
  • Tools analyze

Per-Attachment Access #

For requests that reference media items, the handlers also enforce per-attachment checks with current_user_can( 'edit_post', $attachment_id ). The loaded docs confirm that this check is applied in Image, H2I, and Tools flows.

This matters especially in bulk workflows. A user may have general access to the plugin’s feature routes but still fail a request if one or more selected attachments are not editable by that user.

REST Nonce Requirements #

The plugin’s feature routes and log routes are protected by WordPress REST nonce validation.

Header Name and Nonce Action #

The loaded docs confirm:

  • header key: x_wp_nonce
  • nonce action: wp_rest

The troubleshooting guide documents the specific error emitted when this check fails:

  • error code: davix_h2i_invalid_nonce
  • HTTP status: 403

Where Nonce Validation Applies #

Nonce validation is documented for:

  • feature REST routes through davix_h2i_rest_permissions()
  • log REST routes through davix_h2i_log_permissions()

The admin UI receives the nonce through the localized DavixH2IData object, which includes nonce for client-side requests.

That means the plugin’s interactive admin workflows are documented as authenticated WordPress-admin operations, not open public endpoints.

Attachment Permission Checks #

Beyond global capability checks, the plugin validates attachment-level permissions before processing files.

Image Workflows #

Image preview and generate validate every selected attachment with current_user_can( 'edit_post', $attachment_id ). If this fails, the documented error is davix_h2i_forbidden_attachment.

H2I Workflows #

The H2I handlers also validate attachment edit permission where attachment context is used, including bulk attachment-based rendering flows. The troubleshooting guide identifies the same forbidden-attachment condition for H2I handlers.

Tools Workflows #

The Tools handler performs the same attachment edit check for each selected ID before analysis. If one or more attachments are not editable by the current user, the request fails.

This attachment-level model is an important part of the plugin’s security design because it prevents broad media operations from bypassing normal WordPress media ownership or edit permissions.

API Key Handling #

The plugin stores the API key in option davix_h2i_api_key, represented by DAVIX_H2I_OPTION_API_KEY. It is used by the outbound PixLab client when building authentication headers.

Authentication Header Behavior #

The loaded integration and security docs confirm:

  • if auth mode is bearer, the plugin sends Authorization: Bearer <api_key>
  • otherwise, it sends X-Api-Key: <api_key>
  • the default and fallback auth mode is x-api-key

Settings Access for Credentials #

The API key is configured through the plugin settings UI, which requires manage_options. That means credential configuration is restricted to administrators or users with equivalent capability mapping.

Activation and Storage Behavior #

Activation only ensures the API key option exists and is stored with autoload disabled. The admin-operations docs confirm that activation does not perform wider credential bootstrapping beyond that option-state preparation.

API Key Sanitization in Settings #

The installation docs confirm that when saving the API key:

  • input is sanitized through sanitize_text_field( wp_unslash( $value ) )
  • blank submission preserves the existing stored key
  • non-empty input replaces the stored value

That means accidental blank saves do not clear the configured key.

HTTPS and Base URL Restrictions #

The plugin enforces HTTPS for outbound service communication.

Base URL Must Be HTTPS #

The integration and troubleshooting docs confirm that the shared request client rejects non-HTTPS base URLs. The documented error code is:

  • davix_h2i_insecure_base_url

The default PixLab base URL constant is:

  • DAVIX_H2I_PIXLAB_BASE_URL = https://pixlab.davix.dev/

Base URL Normalization and Service Restriction #

The client resolves the base URL through davix_h2i_get_base_url(), applies the davix_h2i_base_url filter, then normalizes the result. The service URL builder only accepts these service names:

  • image
  • h2i
  • tools

Outbound request URLs are built as:

  • <base>/v1/image
  • <base>/v1/h2i
  • <base>/v1/tools

This means the documented outbound surface is narrowly defined rather than open-ended.

Download URL Restrictions #

The plugin restricts where generated results can be downloaded from.

The installation and security docs confirm:

  • downloaded result URLs must use HTTPS
  • downloaded result URLs must be restricted to the configured base host
  • disallowed download URLs return davix_h2i_disallowed_download_url

This restriction applies to workflows that download output after upstream processing, such as Image generate, H2I generate, and upload-time auto-optimize when the upstream response provides a URL result.

That behavior is part of the plugin’s security model because it limits file-fetching to the trusted configured service host.

Data Sent to the H2I engine (PixLab) #

The integration and security documentation describes what the plugin sends to PixLab by feature area.

Image Requests #

Image requests use multipart form data. The plugin sends:

  • uploaded attachment file bytes under multipart images
  • action=multitask
  • selected image field parameters, sanitized from allowed image fields

The loaded docs also confirm that only allowed image fields are sent, after chip and field filtering.

H2I Requests #

H2I requests use JSON. The plugin conditionally sends:

  • action
  • html
  • optional css
  • optional width
  • optional height
  • optional format

The docs also confirm that HTML and CSS are processed through token replacement before the request is sent.

Tools Requests #

Tools requests also use multipart form data. The plugin sends selected image files and the validated tool configuration values for hash and similarity analysis.

From a customer-facing security perspective, the important point is that the plugin builds explicit request payloads for supported workflows. The loaded docs do not describe it as forwarding arbitrary WordPress data wholesale.

Logging and Privacy-Relevant Behavior #

The plugin includes an optional logging subsystem controlled by davix_h2i_log_enabled. When enabled, logs are written under uploads in a tokenized log file path inside davix-h2i/logs. The plugin also creates hardening files in that directory:

  • index.php
  • .htaccess
  • web.config

Log Access Controls #

Log access is restricted through:

  • manage_options
  • REST nonce validation for log routes
  • admin-post and AJAX permission checks for log viewing actions

Safe Log Rendering #

The security and privacy reference confirms that log output is escaped before being rendered in supported viewing paths. It specifically notes:

  • settings page renders option values with escaped output functions
  • log viewer outputs are escaped
  • the standalone log viewer also escapes output and validates nonce and capability

That makes the log system relevant to both permissions and output-safety concerns.

Admin Surface and Request Security Summary #

The plugin’s security model in the loaded files is built from several layers working together:

  • administrator-only settings and log access through manage_options
  • authenticated REST requests with x_wp_nonce and wp_rest nonce validation
  • media-operation access through upload_files
  • per-attachment edit_post permission checks
  • API-key authentication to PixLab using the configured auth mode
  • HTTPS-only base URL enforcement
  • host-restricted and HTTPS-only download URLs
  • hardened log storage and restricted log viewing paths

Safe Operational Notes #

The loaded public-safe docs support these practical security implications:

  • disable logging after incident triage if you no longer need active diagnostics
  • use an account with manage_options to configure credentials and logs
  • use accounts with upload_files and attachment edit rights for media workflows
  • keep the resolved PixLab base URL on HTTPS
  • keep uploads storage writable but access-controlled in normal WordPress hosting practice, since logs and processed files depend on uploads-backed storage
Was it helpful ?
Table of contents
Login
Login
Login
Login
Scroll to Top