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 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

Never store secrets like API keys directly 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

Always send data over HTTPS to Pipedream endpoints.

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.

Require authorization for HTTP triggers

HTTP triggers are public by default, and require no authorization or token to invoke.

For many workflows, you should configure authorization to ensure that only authorized parties can invoke your HTTP trigger.

For third-party services like webhooks, that authorize requests using their own mechanism, use the Validate Webhook Auth action. This supports common auth options, and you don’t have to write any code to configure it.

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.