Security Best Practices

Pipedream implements a range of privacy and security measures meant to protect your data from unauthorized access. Since Pipedream workflows, event sources, and other resources can run any Node.js code and process any event data, you also have a responsibility to ensure you handle that code and data securely. We've outlined a handful of best practices for that below.

Store secrets as Pipedream connected accounts or environment variables

Even if your workflow code is private, you should never store secrets like API keys in code. These secrets should be stored in one of two ways:

• If Pipedream integrates with the app, use connected accounts to link your apps / APIs.
• If you need to store credentials for an app Pipedream doesn't support, or you need to store arbitrary configuration data, use environment variables.

Read more about how Pipedream secures connected accounts / environment variables here.

Deliver data to Pipedream securely

Whenever possible, encrypt data in transit to Pipedream. For example, use HTTPS endpoints when sending HTTP traffic to a workflow.

Send data out of Pipedream securely

When you connect to APIs in a workflow, or deliver data to third-party destinations, encrypt that data in transit. For example, use HTTPS endpoints when sending HTTP traffic to third parties.

Add authentication to incoming event data

You can add many public-facing triggers to your workflows. For example, when you add an HTTP trigger to your workflow, anyone with the associated trigger URL can invoke it. You should protect your workflow with an authentication mechanism like Basic Auth, JWT, or others.

The easiest way to do this is to use the Validate Webhook Auth action. This supports common auth options, and you don't have to write any code to configure it.

If you need to implement custom logic in code, see this workflow for a shared API key example. This reads the header x-api-key and compares it to the environment variable called YOUR_WEBHOOK_API_KEY. If the x-api-key header does not match this variable, it returns a 401 Unauthorized error and exits the workflow early.

This pattern is typical for protecting workflows: add the authentication logic in a step at the top of your workflow, ending early if auth fails. If auth succeeds, Pipedream runs the remaining steps of your workflow.

Validate signatures for incoming events, where available

Many apps pass a signature with event data delivered via webhooks (or other push delivery systems). The signature is an opaque value computed from the incoming event data and a secret that only you and the app know. When you receive the event, you can validate the signature by computing it yourself and comparing it to the signature sent by the app. If the two values match, it verifies that the app sent the data, and not some third party.

Signatures are specific to the app sending the data, and the app should provide instructions for signature validation. Not all apps compute signatures, but when they do, you should always verify them.

When you use a Pipedream event source as your workflow trigger, Pipedream should verify the signature for you. You can always audit the code behind the event source to confirm this, and suggest further security improvements that you find.

See Stripe's signature docs for a real-world example. Pipedream's Stripe event source verifies this signature for you.

Audit code or packages you use within a workflow

Pipedream workflows are just code. Pipedream provides prebuilt triggers and actions that facilitate common use cases, but these are written and run as code within your workflow. You can examine and modify this code in any way you'd like.

This also means that you can audit the code for any triggers or actions you use in your workflow. We encourage this as a best practice. Even code authored by Pipedream can be improved, and if you notice a vulnerability or other issue, you can submit a patch or raise an issue in our GitHub repo.

The same follows for npm packages. Before you use a new npm package in your workflow, review its page on npm and its repo, if available. Good packages should have recent updates. The package should have a healthy number of downloads and related activity (like GitHub stars), and the package author should be responsive to issues raised by the community. If you don't observe these signals, be wary of using the package in your workflow.

Limit what you log and return from steps

Pipedream retains a limited history of event data and associated logs for event sources and workflows. But if you cannot log specific data in Pipedream for privacy / security reasons, or if you want to limit risk, remember that Pipedream only stores data returned from or logged in steps. Specifically, Pipedream will only store:

• The event data emitted from event sources, and any console logs / errors
• The event data that triggers your workflow, any console logs / errors, step exports, and any data included in error stack traces.

Variables stored in memory that aren't logged or returned from steps are not included in Pipedream logs. Since you can modify any code in your Pipedream workflow, if you want to limit what gets logged from a Pipedream action or other step, you can adjust the code accordingly, removing any logs or step exports.