How to build secure integrations (5 tips)
Integrations often deal with a range of sensitive data, whether it's personally identifiable information (PII) on employees, business financials, sensitive information on customers, and so on.
To ensure this information is kept secure over time, you should adopt a variety of security measures and, if you’re using a 3rd-party integration solution, use a platform that’s adopted the proper security protocols and features.
We’ll break down best practices for protecting your integration data and the security features to look for in 3rd-party platforms. But first, let’s align on the definition of integration security and the challenges of securing this data successfully.
Overview on integration security
It's a set measures that your business and your 3rd-party vendors take to protect integration data. These measures can take the form of authentication processes, policies for storing and using sensitive data, scopes for restricting the data that’s synced, and more.
Related: An overview on API integration security
Integration security challenges
While integration security is critical, performing it successfully is anything but.
Here are a few common challenges to keep in mind when building and maintaining your integrations:
Certain integration methods are less secure
Integrating data through files or scripts is often less secure than using application programming interfaces (APIs).
When integrating data via files, for example, you may need to store the files in an intermediate system that’s vulnerable to unauthorized access. And, in the case of scripts, they may fail to encrypt data during transmissions effectively, making their data prone to interceptions.
Since APIs aren’t always available—whether that’s because the 3rd-party application doesn’t offer APIs or doesn’t provide the specific endpoints you need—you may be forced to adopt file or script-based integrations, which means facing the security risks of either approach.
Related: Hows APIs and screen scraping compare
Difficult to set up and maintain scopes at scale
Many 3rd-party integration tools don’t offer scopes—or the ability to customize the data that can be accessed and synced for a given authorized client—out of the box. And tasking in-house engineers with setting them up can prove difficult; it can be extremely time and resource intensive to implement and maintain each scope, and as the number of integrations you implement increases, the work around setting up and maintaining scopes only grows.
The sheer amount of work involved in managing scopes—if managed in-house—can also lead to human errors that either provide API consumers with too much access (which naturally poses a security risk) or not enough (which is a poor experience for your API consumers).
Hard to use API logs effectively for identifying and addressing security issues
API logs can play a critical role in surfacing security issues, but in order for them to do so, they'll need to collect and display enough information from a given API request.
This can easily turn to overly-comprehensive logs that are difficult to sift through, analyze, and take action from—especially as you scale your integrations and the number of API calls you make.
You’ll ultimately need to strike the right balance of information, which can be an exercise that your team doesn’t figure out successfully or quickly.
Integration security best practices
To help you build secure integrations, it’s worth keeping the following in mind:
Use APIs when possible
As mentioned previously, APIs offer a more secure integration method than alternative approaches. They use authentication and authorization mechanisms like API keys and tokens; they often use HTTPS to encrypt data in transit; they generate detailed logs, and more.
With this in mind, prioritize API-based integrations when thinking through your integration approaches.
Build automated processes for resolving security issues
You’re likely to run into certain integration security issues frequently, such as consumers exceeding their API rate limits. To help you pinpoint and resolve these issues on time, you can build internal workflow automations.
For example, you can connect the tool that generates API logs and detects issues (e.g., Datadog) with the application your engineers already work in (e.g., Slack) and build a flow where once a certain issue is detected in the former, a preconfigured message gets to a specific channel in the latter. The message can alert your team of the issue and the suggested steps to troubleshoot and resolve it.
Related: A guide handling API errors
Perform extensive integration security tests
You can build significantly more secure integrations by testing them extensively and addressing any of their security vulnerabilities before pushing them to production.
This can be performing routine code reviews to look for potential vulnerabilities, conducting penetration testing to uncover weaknesses, authentication testing to verify that your authentication mechanisms work correctly, and so on.
Protect your API keys and tokens
If your API keys or tokens get leaked, malicious actors may be able to access highly-sensitive data. To prevent this from happening, you can limit the lifespans of your tokens and API keys; use a secure vault service to store credentials; avoid hardcoding them in your source code, and more.
Carefully review the 3rd-party integration solutions from a security lens
Every 3rd-party integration solution has a unique set of features, policies, and processes when it comes to handling and protecting sensitive data.
It’s in your best interest to review each of these aspects across potential vendors to ensure you pick the solution that has the best overall approach to security (among other areas).
With this in mind, we’ll review the top areas you should evaluate for a given vendor in the following section.
How to evaluate integration security features in 3rd-party solutions
Here’s the criteria you should use during your vendor evaluations:
Assess the vendors’ security and compliance credentials
By simply scanning vendors’ sites, you should be able to tell whether they adhere to compliance frameworks, like GDPR, SOC 2 Type II, ISO 27001, etc.
You should also double check these claims by reviewing the documentation that validates a given vendor’s compliance with a security framework. And if this documentation isn’t available on their site, you can ask your assigned sales rep for a copy.
Review the vendors’ security features and capabilities
There’s a wide range of features that can help you protect your integration data.
Scopes, as an example, can help ensure that you follow the principle of least privilege, as it lets you restrict the data you’re able to access from a given integration.
Scopes should also provide fine-grained features for accessing and performing actions on data. For example, it should let you select from actions like “Read” or “Write”; and it should let you apply scopes for either individual customers (with especially stringent security needs) or everyone.
Here are just a few more features to look for:
- Role-based access control: You should be able to assign roles to different users so that only the right set of individuals can view and perform actions on specific types of data
- Audit trail: You should be able to view all of the activities that users take in the integration solution so that you can easily identify the sources of issues over time
- Multi-tenant support: You should be able to store data in the regions that you and your customers operate in, as doing so is likely necessary for meeting your data residency requirements and that of your customers
Related: Merge now offers a multi-tenant in APAC
Review the types of integrations the platforms support
As mentioned earlier, API-based integrations are generally the most secure, so it’s worth verifying with vendors that the integrations you care about are supported by APIs—or through another mechanism.
For example, Finch offers “assisted integrations”, which are performed manually and in a way that’s problematic from a security (and performance) perspective:
If there's ambiguous language around the integration method involved—such as assisted integrations—you should ask for specifics on how it works so that you can get a full picture of the security risks you'd take on.
{{this-blog-only-cta}}