Integration Security: What to Ask Your Ecommerce Integration Vendor Before You Connect

When you connect an integration tool to your ecommerce stack, you are handing that vendor the keys to your business. Access to your orders, customer records, financial data, and inventory. If that vendor handles your credentials carelessly, anyone could read your customer data, delete records, or pull financial reports you never intended to share.

Most businesses never ask the right questions before signing up. This post covers exactly what to ask, why it matters, and what a secure answer looks like, using our own security posture at Connex as the benchmark.

The core risk: An access token is essentially a special password that grants read/write access to your platform. Combined with a Client ID and secret, it can be used to make changes on your behalf. If those credentials are stored or transmitted carelessly, the consequences range from data leaks to complete account compromise.

Here is the checklist we recommend running through with any integration vendor before you connect.

1. How Are Your Access Tokens and Credentials Stored?

This is the first question to ask, and the answer will tell you a lot about how seriously a vendor takes security.

An access token, combined with a Client ID and client secret, gives a vendor the ability to read and write data on your behalf. If those values are hardcoded into application source code, committed to a repository, or stored in a plain text config file, they are a breach waiting to happen.

What a bad answer looks like: "We store credentials in our database" or "they're in the config file." These are red flags.

What a good answer looks like: Credentials should be stored in environment variables or a secrets management service, never embedded in source code.

How Connex Handles This

At Connex, application credentials and client secrets are maintained in Azure App Service environment variables, not in our source code. This means even if someone accessed our codebase, they would not find your credentials. Secret values are masked in the Azure Portal by default, adding another layer of protection.

The risk of hardcoded tokens is well-documented. A single exposed GitHub repository containing a hardcoded access token can result in full account compromise within minutes of discovery.

2. Is There a Firewall and Database Encryption?

If the integration stores any of your data in a database, two follow-up questions are non-negotiable.

Firewall Protection

A firewall around the database ensures that only authorized systems inside the vendor's infrastructure can query it. Without one, a misconfigured server or exposed port could allow anyone on the internet to attempt a direct connection.

Ask specifically: "Is your database protected by a network-level firewall? Who can access it from outside your infrastructure?"

A good vendor will confirm that database access is restricted to internal application servers only, with no public-facing endpoints.

Encryption at Rest

Even if someone were to obtain a copy of the database files, encryption at rest makes that data unreadable without the correct decryption keys.

What to ask: "Is your database encrypted at rest? What encryption standard do you use?"

At Connex, we use Azure SQL with Transparent Data Encryption (TDE) enabled by default. TDE automatically encrypts data files, log files, and backups using AES-256 encryption. You do not need to change your application to benefit from it; it operates at the storage layer.

3. Access Control: Who Can Do What, and What Happens When Something Goes Wrong?

Access control is about more than just passwords. It covers how the integration handles user permissions, error recovery, and account lockouts.

Questions to Ask

• Is there a UI for the integration? If so, how are user roles and permissions managed? Can a low-privilege user accidentally (or intentionally) access data they should not see?
• What happens after repeated failed login attempts? A secure system should lock out a user after a defined number of failures. We recommend asking whether lockout triggers after 10 failed attempts, and whether your team is alerted when it happens.
• How do you fix errors when they occur? Ask for specifics. Does the vendor have an error log? A support escalation process? Automated alerts?

Tenant Isolation: Can Someone Else's User Access Your Data?

This is one of the most important questions for multi-tenant SaaS integrations. If the platform serves multiple customers on shared infrastructure, there must be strict data isolation between accounts.

Ask directly: "Is this integration multi-tenant? If so, how do you ensure that User A cannot access User B's records?"

The technical answer should include row-level security or tenant-scoped queries, meaning every database query is automatically filtered by the authenticated customer's account ID. This prevents a bug or misconfiguration from leaking one customer's data to another.

Also ask: "How do you prevent SQL injection attacks?" A well-maintained integration uses parameterized queries or an ORM that handles escaping automatically. If the vendor cannot answer this question clearly, that is a serious concern.

4. What Happens to Your Customer Data (PII)?

Personally identifiable information (PII) like customer names, addresses, and email addresses is one of the most sensitive categories of data your integration will touch. You need to understand exactly how it flows.

There are two very different scenarios:

1. Pass-through only: The integration reads the data, formats it, and sends it to the destination system (QuickBooks, HubSpot, etc.) without storing it. This is the lower-risk model.
2. Persisted storage: The integration stores customer data in its own database, even temporarily. This creates a second location where a breach could expose your customers.

Key Questions on PII

• "Do you store customer names, addresses, or contact information in your own database?"
• "If yes, how long is that data retained? Is there a deletion policy?"
• "Are you compliant with relevant data regulations (GDPR, CCPA) for the regions where my customers are located?"

A vendor who persists PII without a clear retention and deletion policy is a liability. The right answer is either that data is not stored at all, or that there is a defined retention window with automatic deletion and documented compliance controls.

5. Where Is the Integration Hosted and Who Handles Security Patching?

Hosting infrastructure matters. A vendor running their application on an unmanaged virtual machine with no patch schedule is a very different risk profile than one using a managed cloud platform with built-in security controls.

What to Ask About Hosting

• "Where is your application hosted? Is it a managed cloud platform or self-managed servers?"
• "Who is responsible for OS-level patching and updates?"
• "Who handles anti-virus and malware protection on your servers?"

Managed platforms like Microsoft Azure App Service handle much of the underlying infrastructure security automatically, including patching the underlying OS and runtime. This reduces the attack surface compared to a vendor managing their own bare-metal or unmanaged VM.

At Connex, our API is hosted on Microsoft Azure App Service. For endpoint protection on any Windows-based tooling, we use Windows Defender and can provide scan reports on request.

Ask for evidence. A vendor who takes this seriously will be able to share a recent scan report or infrastructure diagram without hesitation. If they cannot, or if they seem surprised by the question, treat that as a warning sign.

6. Has This Integration Been Penetration Tested?

A penetration test (pen test) is when a security professional attempts to break into a system, the same way a real attacker would, and documents what they find. It is one of the most reliable ways to verify that a vendor's security controls actually work under adversarial conditions.

What to Ask

• "Do you conduct regular penetration tests? How often?"
• "Who performs the tests, an internal team or an independent third party?"
• "Can you share the findings from your most recent test, and how were those issues remediated?"

The last question is the most revealing. Every pen test finds something. A vendor who claims a clean report without any findings is either not sharing the full picture or not testing thoroughly enough. What matters is how quickly and completely they fixed what was found.

What good looks like: A reputable vendor commissions an independent pen test at least annually, shares a summary of findings with enterprise customers on request, and can demonstrate that critical and high-severity issues were remediated before the next release cycle.

A vendor who has never been pen tested, or who cannot produce any documentation, is asking you to trust their security on faith alone. That is not an acceptable answer when your customer data is on the line.

7. What Is Their Data Breach and Incident Response Plan?

No system is perfectly immune to a breach. What separates a responsible vendor from a reckless one is whether they have a documented, tested plan for what happens when something goes wrong.

Questions to Ask Before Signing

• "Do you have a documented incident response plan?"
• "How quickly would you notify us in the event of a breach affecting our data?"
• "Who is the point of contact for security incidents?"
• "Have you experienced a data breach before? If so, how was it handled?"

The answers should be specific. Vague responses like "we take security very seriously" or "we would notify you promptly" are not acceptable. You want a named contact, a defined notification window (ideally within 24 to 72 hours), and a clear description of the investigation and remediation process.

The Architecture Question

Ask the vendor to walk you through their system architecture from a security perspective. A confident, security-minded team should be able to explain, without hesitation, how data moves through their system, where it is stored, who can access it, and what controls exist at each layer.

If they cannot produce a basic architecture diagram or walk you through the data flow, that gap in documentation is itself a risk signal.

Running through this checklist takes less than an hour and can save you from a vendor relationship that puts your business, and your customers, at serious risk. The best vendors will welcome these questions. They have already thought through the answers.

The Full Security Checklist at a Glance

Use this as a reference when evaluating any integration vendor.

If you are evaluating Connex and want to discuss any of these questions directly, contact our team. We are happy to walk through our security posture, share relevant documentation, and answer your specific concerns before you connect your first channel.