Security Model

The Davix H2I n8n node uses a credential-based security model centered on a single custom credential type and an HTTPS-only outbound request path. The repository documentation describes security in terms of:

• credential handling
• authentication transmission
• request construction
• input validation
• binary and download behavior
• what is and is not logged in runtime code

This page documents only the security behavior confirmed by the node documentation and implementation-backed SSOT.

Security model overview #

The node defines one credential type: Davix H2I (PixLab) API. That credential stores:

• a Base URL
• an API Key

At runtime, the node:

• reads the saved credential
• validates the Base URL
• checks that the API key is present
• injects the API key into the outbound request header
• sends the request to the selected endpoint path under the configured Base URL

The documented security posture of the node is therefore based on:

• protected credential entry in the n8n UI
• validation of connection settings before dispatch
• HTTPS enforcement
• header-based API-key authentication
• explicit request construction rather than automatic forwarding of arbitrary item data

Credential handling #

The credential type is implemented as DavixH2IApi, with public display name Davix H2I (PixLab) API. The internal credential name used by the node is davixH2IApi.

The credential defines two fields.

Base URL #

• internal name: baseUrl
• type: string
• required: true
• default: https://pixlab.davix.dev
• placeholder: https://pixlab.davix.dev

API Key #

• internal name: apiKey
• type: string
• required: true
• default: empty string
• password-style input enabled through typeOptions: { password: true }

The security documentation confirms that credentials are retrieved at request time and read as creds.baseUrl and creds.apiKey. It also confirms that:

• the API key is not transformed by hashing, signing, or encoding in repository code
• it is inserted directly into request headers
• no explicit credential logging statements are documented in the runtime node code

[Image placeholder — n8n credential screen showing the Base URL field and password-style API Key field]

Authentication transmission #

The node sends authentication using a custom HTTP header:

• x-api-key

The request helper builds request options by merging existing headers and adding x-api-key: apiKey. This is the implemented authentication mechanism for all resource requests.

The documentation also confirms that:

• the Base URL is credential-configurable
• the helper appends endpoint paths such as /v1/h2i, /v1/image, /v1/pdf, and /v1/tools to the validated Base URL

The repository does not document Bearer authentication, OAuth, or alternate authentication modes for this node. The supported documented method is API key authentication through x-api-key.

Base URL validation and transport security #

Before sending requests, the helper validates the configured Base URL. The documented validation rules are:

• Base URL must be present
• Base URL must be a valid absolute URL
• Base URL must use https:
• Base URL must not contain embedded credentials such as user:pass@host

This is a core part of the node’s connection security model:

• the node does not accept insecure HTTP base URLs
• the node does not allow embedded credentials in the URL field
• the node requires a clean HTTPS Base URL plus a separate API key credential field

Request construction and data exposure #

The security documentation states that the node does not forward the entire incoming item JSON automatically. Instead, it builds request payloads explicitly from declared node parameters.

The documented request styles are:

• H2I → JSON body
• Image → multipart formData
• PDF → multipart formData
• Tools → multipart formData

The security documentation further confirms:

• H2I requests send selected fields such as action, HTML, CSS, dimensions, and operation-dependent fields
• Image, PDF, and Tools requests use multipart form data built from declared parameters and attached binary inputs
• user-provided password fields for PDF operations are copied into form data only when those operations are selected
• the node does not automatically send unrelated input JSON fields from the n8n item

This means the node’s request surface is constrained by its field model rather than by arbitrary pass-through of the entire incoming item.

Sensitive UI fields #

In addition to the main API key credential field, the node also defines password-style UI fields for certain PDF workflows. These include:

• userPassword
• ownerPassword
• password

These fields are used for PDF encrypt and decrypt operations and are marked as password-style fields in the node UI.

For public documentation, the correct conclusion is:

• the node uses password-style handling for credential secrets
• the node also uses password-style handling for PDF protection fields shown in relevant PDF operations

Input validation as a security control #

Several runtime validations also function as security-relevant controls because they prevent malformed or unsafe request configuration from being sent.

Documented validation includes:

• Base URL presence and format checks
• HTTPS-only requirement
• rejection of embedded URL credentials
• required API key
• binary property list validation
• upload-size validation
• operation-specific validation such as required multitask selections and valid reorder input for PDF reorder

Together, these validations reduce accidental overbroad or malformed requests.

Upload-size protection #

The node includes upload-size validation for binary uploads. For exact numeric limits and related failure details, refer to the shared Errors and Limits page.

Download and binary-output security behavior #

The node can optionally download returned URLs and convert them into n8n binary output for:

• H2I
• Image
• PDF

The documented behavior is:

• gather returned URLs from the response
• download file content
• attach the content as n8n binary data under the configured binary property field

From a security-model perspective, the confirmed behavior is limited to that implementation. The repository documentation does not confirm:

• a separate allowlist system for output download URLs in the n8n node
• a secondary host-restriction layer for returned file downloads inside this node
• special runtime sanitization of returned URLs beyond the documented request and output flow

The correct public wording is therefore that the node downloads returned URLs when the user explicitly enables binary download for supported resources, and those downloads become part of the workflow output.

Logging and debug exposure #

The observability documentation states that this repository does not implement explicit runtime logging inside the node code. It also confirms:

• no documented console.log statements in runtime node files
• no explicit debug flag in execution logic
• no documented runtime logging framework in the node code

The security documentation adds:

• no explicit credential logging statements are present
• no credential masking or redaction function is documented in the runtime request/response path

Taken together, that supports a narrow evidence-based statement:

• the node does not document explicit runtime credential logging
• the node also does not document a dedicated masking or redaction subsystem in its request and response handling code

Error visibility and exposure #

When errors occur, the request helper can surface:

• message
• optional description
• optional httpCode

It may also incorporate parsed backend fields such as hint and requestId when available.

This matters for the security model because it defines what failure information can appear in workflow output when continueOnFail() is enabled. The documentation does not confirm explicit secret-redaction logic for those surfaced backend fields; it documents only how errors are parsed and emitted.

Resource scope of the security model #

The security model applies across all four resources:

• H2I
• Image
• PDF
• Tools

All four use:

• the same credential type
• the same request helper
• the same Base URL validation path
• the same API-key injection mechanism

That means security behavior is centralized at the credential and request-helper level rather than being redefined separately for each resource.

What is not documented as a security feature #

The repository documentation does not confirm any of the following for this node:

• OAuth flows
• Bearer token auth mode
• request signing
• built-in retry or backoff as a resilience/security feature
• runtime audit logging
• secret redaction middleware
• custom certificate configuration
• documented allowlist restrictions on downloaded output URLs
• workflow-level access control beyond what n8n itself provides outside this repository

These features should not be claimed in public documentation.

Security summary #

The code-backed security model for the n8n node is:

• one credential type with Base URL and API Key
• password-style input for the API key and certain PDF password fields
• HTTPS-only Base URL validation
• rejection of embedded credentials in the Base URL
• API key sent in the x-api-key header
• explicit request construction from declared node parameters
• upload-size validation
• optional binary download for supported resources
• no documented runtime logging subsystem inside the node code

[Image placeholder — n8n node panel showing the selected credential and a PDF password field in an encrypt/decrypt workflow]