Building securely

Log retention​

Copy

The retention of your workflow execution data, viewable in the Debug Log, can be reduced down to 24hrs or be disabled entirely. We call the latter ghost processing.

• With ghost processing, no log data is generated for viewing within the workflow. The workflow data is however stored in our internal systems for 24hrs. This is for availability reasons in the event that an aspect of the platform has a problem, it can be automatically retried.

It's important to note that changing the log retention will apply to all workflows in the Organization.

Reducing the retention of workflow logs or disabling it entirely can make troubleshooting workflows difficult. You can still take advantage of:

• Error reporting: By forwarding error reports to a separate workflow so they can be surfaced elsewhere (eg: slack/internal support ticket).

• Log streaming: Available regardless of your log retention period. This allows you to stream your workflow execution data to your own systems or SIEM so you can set your own retention period.

Tray's internal access to workflow logs is limited as per Support Access controls.

Data encryption​

Copy

Encrypting data​

Copy

Tray's Crypto Helpers can be used to encrypt/decrypt data within your workflows using the available algorithms (CIV, Hmac, Hash etc.)

Encrypting files​

Copy

Tray's Encryption Helpers uses PGP encryption to both:

• Encrypt files to be sent to a particular destination

• Receive and decrypt files

A typical setup would be to import an encrypted file with our FTP Client and then decrypt it with the Encryption Helpers 'PGP Decrypt file' operation.

Verifying data​

Copy

Tray's JWT Helper can be used to sign / verify data with JSON Web Tokens.

Authentications​

Copy

As per Tray's security policies we implement data encryption at rest and additional encryption for extra sensitive data like workflow authentications (API keys, access tokens etc).

We also redact workflow authentications from workflow input logs.

You should never hardcode any auth information in the Tray builder - the $.auth environment path can be used if e.g. an API token is needed to be passed as a header in an HTTP Client step.

Securing webhook urls​

Copy

Each webhook generated by Tray has a public url in a format which includes a UUID:

https://c5272511-xxxx-xxxx-xxxx-90ff4062627b.trayapp.io

Whilst these are almost impossible to guess or brute force, we strongly recommend further securing your webhooks. You can either:

1. Require a CSRF token in the header of the webhook. Then, webhook calls with an incorrect or missing CSRF token are rejected and not seen in your logs. See Webhook security documentation.

   • Embedded customers can generate a different CSRF token per End User / Solution Instance by using env variables / config variables

2. Convert your webhook into an API and create your own Clients, Policies and Roles. See API management overview, and below.

Entry Point Triggers vs API Management

Copy

When building secure workflows, it's critical to carefully consider how your workflows are triggered. While entry point triggers like Webhook, Form, and Email offer convenience, they can introduce potential security vulnerabilities, especially when handling sensitive or confidential data.

Entry point triggers allow external systems or users to initiate workflows, but they can leave your workflows exposed to risks such as:

• Unverified Requests: Webhooks or forms can be accessed or triggered by unauthorized parties, leading to potential data leaks.

• Confidential Data Exposure: Sensitive information, like x-csrf-token, may be inadvertently shared or exploited.

• Limited Access Control: Entry point triggers often lack robust methods to verify or restrict who is authorized to initiate workflows, increasing the risk of unauthorized actions.

To address these vulnerabilities, we recommend leveraging API Management (APIM) for enhanced security, control, and traceability.

Why use API Management?

Copy

API Management (APIM) offers a secure and scalable alternative to entry point triggers by enforcing the AAA framework — Authenticate, Authorize, and Audit — for every API request:

1. Authenticate: Endpoints (workflows) are only triggered by API Clients and Tokens that you've created.

2. Authorize: Assign your API Clients to Policies and permit access to only the endpoints you've authorised. This allows you to manage access on the basis of least privilege.

3. Audit: All successful API calls are logged in the workflow. Tracking which Client accessed what, when, and what actions were taken. This allows for thorough oversight and review of all workflow interactions.