Handling Sensitive Data
When authoring recipes, Workato strongly recommends that you avoid placing sensitive data as plain text within the steps of a recipe. This especially applies tokens or keys used for authentication to remote services, but also to personal information (such as names, addresses, emails) and anything else that should be kept private to the recipe author.
To avoid sensitive data in recipe steps:
-
Do not place authentication information used for a Connector (the HTTP Connector for example) in the recipe, as a hard-coded string. For example, don't specify a URL such as https://www.myapp.com/services/api-method?token=3ababe3235Z2z in the recipe. The best practice is to store the authentication token in the properties for the Connection. See for example setting up authentication with a query parameter.
-
For other sensitive data, consider placing it in the Environment Properties and make reference to it as needed in recipes.
-
Another approach is to use a data pill to pass the sensitive data from a previous step to the current step. (This assumes that prior step has also not used hard-coded sensitive data).
Following these guidelines will have the following security benefits:
-
Sensitive data will not be exposed to other users within your Workato Team environment.
-
Sensitive data will not be exposed when a recipe is cloned. When a recipe is cloned, and copied into another Workato account, data that is part of the recipe steps will be copied, but Connection properties and Environment Properties are not copied, nor are the dynamic contents of data pills.
-
It will be easier to maintain and manage sensitive information, because that information will be centralized, rather than spread across disparate recipes.
-
If you decide to share your recipe with the community at some point by making it public, no sensitive data will be exposed.
Workato API recipes are a powerful feature that allows access to Workato functionality from sources external to Workato. But, since recipes can perform operations on your business systems, it is important to avoid unauthorized access to them through APIs.
Treat API tokens like a password
API tokens should be treated like a password. Tokens grant API access to anyone who possesses them.
As a best practice, don't distribute them to clients through insecure channels. Use a secure messaging system or a document system to which both the API owner and the intended client have access.
Don't re-use the same API token
An API token identifies a client and enables monitoring requests in the API dashboard on a per-client basis. If multiple people have the same API token, there's no reliable way to determine who is making calls to your API.
Periodically refresh API tokens
By periodically refreshing (or changing) API tokens, you can ensure compromise of an API token doesn't provide long-term access. Refreshing an API token is similar to the way passwords expire.
Alternatively, distribute a JWT token and set an expiration time. This will give the token a limited lifetime.
Use IP allowedlists
Adding IP addresses to the allowedlist restricts the originating IP addresses that have API access. This can be done as part of a client's Access Profile.
An allowedlist is a best practice from a security perspective, but there are a few things to consider:
- Some clients may not have a fixed IP address. If a client connects from a home network, for example, their internet provider may assign a different IP for each session.
- Some clients may connect from multiple IP addresses. If a client is travelling, for example, they may not have the same IP that they would from their usual network.
In these cases, it may not be readily possible to add IP addresses to the allowedlist.
Consider using JWT tokens
Instead of distributing auth secrets directly, use a JWT token. A JWT token encapsulates the Auth Token secret instead of the secret itself. JWT tokens are signed, include the client identity and can have an expiration. Learn how to set up a JWT token.
Monitor user access to APIs
If a person should no longer have access to APIs, such as a terminated employee, ensure that person's client profile is disabled or deleted in Workato.
