WP-Nexus

Appearance

Security ​

WP-Nexus is designed with security as a core principle. All business logic runs server-side, user input is validated and sanitized, and WordPress security mechanisms are integrated throughout.

Server-Side Action Execution ​

The most important security feature: all action pipelines execute on the server. When a user clicks a button or submits a form:

  1. The browser sends an AJAX request with the action identifier and input data.
  2. The server loads the action pipeline from the database and executes it.
  3. The pipeline definition is never sent to the browser -- users cannot see or modify your workflow logic.

This means your validation rules, database queries, API keys, and business logic are completely hidden from end users.

WordPress Nonce Integration ​

Every AJAX request from WP-Nexus includes a WordPress nonce (a one-time token). The server verifies this nonce before processing any action. This prevents:

  • Cross-Site Request Forgery (CSRF) -- malicious sites cannot trick a user's browser into making requests to your app.
  • Replay attacks -- nonces expire, so captured requests cannot be reused indefinitely.

Nonces are generated automatically; you do not need to configure them.

Input Validation ​

Use the Validate node at the start of your action pipelines to enforce rules on user input:

  • Required fields
  • Minimum/maximum length
  • Numeric ranges
  • Regular expression patterns
  • Custom expressions

Validation happens server-side. Even if a client bypasses frontend validation (e.g., by modifying the DOM), the server rejects invalid input.

Input Sanitization ​

The Sanitize node cleans user input before it reaches your database:

  • Trim whitespace
  • Strip HTML tags from text fields
  • Escape special characters for SQL safety
  • Normalize formats (emails, URLs)

WP-Nexus also uses WordPress's built-in sanitize_text_field(), sanitize_key(), and $wpdb->prepare() functions throughout its internals.

Rate Limiting ​

The Rate Limit node prevents abuse by limiting how many times an action can be triggered within a time window:

  • Configure requests per time period (e.g., 5 per minute)
  • Tracked per IP address or per user
  • Returns an error response when the limit is exceeded

Always add rate limiting to public-facing forms (contact forms, registration, search) to prevent spam and denial-of-service attacks.

Role-Based Access Control (RBAC) ​

Use the Require Auth node to restrict action execution based on WordPress user roles:

  • Require the user to be logged in
  • Require specific roles (administrator, editor, subscriber, or custom roles)
  • Require specific capabilities (edit_posts, manage_options, etc.)

Combine Require Auth with the visibility system in the UI Builder to hide UI elements from unauthorized users while enforcing access on the server.

Expression-Level Auth Functions ​

The expression engine provides auth-aware functions:

  • user_can('capability') -- checks a WordPress capability (e.g., user_can('edit_posts'))
  • user_has_role('role') -- checks if the current user has a specific role (e.g., user_has_role('administrator'))
  • user_meta('key') -- retrieves a user meta field value for the current user

To check if a user is logged in, use user_can('read') -- the read capability is granted to all authenticated WordPress users.

To access the current user's core profile fields (ID, display name, email), use the Current User source node in your pipeline, which provides these as input.id, input.display_name, input.user_email, etc.

These functions query the server-side WordPress user session. They cannot be spoofed from the client.

File Upload Security ​

The File Upload widget and the server-side upload handler enforce multiple layers of security:

  • MIME type validation -- only allowed file types are accepted (configured via the accept property)
  • File size limits -- configurable per widget (default 5 MB)
  • WordPress media library -- uploads go through wp_handle_upload(), which applies all WordPress upload security filters
  • Filename sanitization -- filenames are cleaned to prevent directory traversal attacks

Expression Sanitization ​

Expressions (e.g., { {row.title}}) are evaluated server-side and their output is escaped before rendering into HTML. This prevents:

  • Cross-Site Scripting (XSS) -- user-supplied data cannot inject scripts into the rendered page
  • SQL injection -- expressions are evaluated in a sandboxed context, not concatenated into SQL queries

The only exception is the HTML Block widget, which renders raw HTML by design. Exercise caution when using expressions inside HTML Block content.

Security Checklist ​

When building your app, follow these practices:

  1. Always add Validate and Sanitize nodes at the start of every action that processes user input.
  2. Always add Rate Limit to public-facing actions.
  3. Always add Require Auth to actions that modify data or access sensitive information.
  4. Use the visibility system to hide admin-only UI, but never rely on it alone -- always enforce access on the server.
  5. Restrict file upload types -- only allow the MIME types your app actually needs.
  6. Avoid raw HTML with user-supplied data -- use the Text widget instead of HTML Block when displaying user content.
  7. Test as different roles -- verify that subscribers cannot access administrator-only actions.