Security Assessments for SaaS Integrations: What to Test Before Connecting Customer Accounts

Why an integration is a different risk category than your own application

A standard web application vulnerability assessment or audit tests the boundary between your users and your own systems. An integration adds a second, less familiar boundary: the one between your application and a platform you don't control, using a credential (an OAuth token) that a customer granted you on the assumption you'd protect it as carefully as they would. A vulnerability in your own login page affects your own users. A vulnerability in how you store or scope a Google Workspace or Salesforce access token can affect every customer who has ever connected that integration, all at once, because the blast radius is defined by how many tenants trusted you with a token, not by how many people use your product day to day.

This is also why the Drift incident scaled the way it did. The initial compromise had nothing to do with OAuth. It was a long-dwelling breach of the vendor's own source control, discovered months after the fact. The OAuth abuse was the second stage: once attackers had persistent access to Drift's environment, the tokens sitting in its systems became the actual weapon, giving them legitimate, MFA-bypassing access into every connected customer's Salesforce instance without needing to compromise a single customer directly. A security assessment scoped only to your own login flow would have missed this class of risk entirely. Testing an integration means testing the token, not just the app around it.

OAuth permissions and the scopes your integration actually requests

The first thing a SaaS integration security assessment should check is what your OAuth consent screen is actually asking customers to approve, and whether that request matches what the feature needs. OWASP's OAuth 2.0 Cheat Sheet is direct about this: access tokens should be restricted to the minimum privilege required for the specific use case, restricted to a single Resource Server through audience restriction, and restricted to specific resources and actions rather than broad account-wide access. In practice, that means an integration that only needs to read calendar availability shouldn't be requesting full Gmail read and write access, and an integration that only writes to a specific Salesforce object shouldn't be requesting org-wide API access as a default.

Scope creep is the more common failure mode than an oversized initial request. A product ships with a narrow scope, then a new feature gets added six months later, and the fastest path to shipping it is widening an existing OAuth grant rather than requesting a new, narrower one and re-prompting every customer. A proper vulnerability assessment or audit should include a scope-to-feature map: every permission your integration currently holds, matched to the specific feature that requires it, with no entries left over that nobody can explain. If a scope exists that no current feature actually uses, that's a finding, because it's unnecessary blast radius sitting in every connected customer's environment for no working reason.

The authorization flow itself: PKCE, redirect URIs, and a deprecated grant type still showing up in the wild

Beyond scopes, the mechanics of the authorization flow matter just as much. OWASP's guidance is explicit that the Implicit Grant, the older OAuth flow that returns an access token directly in the URL fragment, is deprecated under RFC 9700 and removed entirely from OAuth 2.1, because tokens returned that way leak through browser history, referrer headers, and proxy or server logs, and can never be cryptographically bound to the client that requested them. Any SaaS integration still using this flow, whether inherited from an old codebase or copied from an outdated tutorial, is a finding that should stop a launch. The current standard is the Authorization Code Grant with PKCE (Proof Key for Code Exchange) for every client type, including single-page apps and native applications, specifically because PKCE prevents an intercepted authorization code from being redeemed by anyone other than the client that originated the request.

Redirect URI handling deserves its own line item. If your OAuth callback accepts anything beyond a strictly allowlisted, exact-match redirect URI, whether through a wildcard subdomain pattern or an unvalidated query parameter, you've built an open redirector, and OWASP flags this specifically because it's a direct path to exfiltrating authorization codes and access tokens by redirecting the flow somewhere the attacker controls. CSRF protection matters here too: without PKCE's built-in protection or a properly implemented state parameter bound to the user's session (or a nonce, if you're layering OpenID Connect on top), an attacker can trick a logged-in user into completing an OAuth grant the user never intended to authorize.

Token storage: the part of the system that turns a feature into a liability

Once a customer authorizes your integration, your application is now holding a live credential capable of acting on their Google Workspace, Salesforce, or Slack data, in most cases until it's explicitly revoked. How that token is stored is where a well-scoped integration and a future breach notification usually diverge. A vulnerability assessment or audit of token storage should verify that access and refresh tokens are encrypted at rest rather than sitting in a database column in plaintext, that tokens are never written to application logs, error trackers, or debug output during exception handling (a mistake that happens constantly, because a stack trace that includes a request object will often include the authorization header along with it), and that refresh tokens in particular are either sender-constrained through DPoP or mutual TLS, or rotated on every use so a replayed token gets flagged instead of silently accepted.

This is precisely the mechanism that made the Drift breach as damaging as it was. The attackers weren't cracking passwords or brute-forcing accounts. They were using tokens that were already valid, already trusted by Salesforce and Google as legitimate, and, this is the part that let the campaign run for ten days before detection, never flagged as anomalous by systems that had no reason to distrust a credential their own authorization server had issued. A vulnerability assessment should also test what happens on disconnect: when a customer revokes access from your side, does your integration actually call the provider's token revocation endpoint, or does it just delete the token from your own database while the token itself remains valid and usable if it ever leaked before that point.

Account isolation: the bug that crosses from your database into someone else's platform

Third-party access risk doesn't stop at the token itself. It extends into how your own multi-tenant architecture maps internal customer accounts to the external data those tokens pull back. This is a different bug class from anything in the OAuth specification, and OWASP treats it separately in its Multi-Tenant Security Cheat Sheet for exactly that reason: the failure isn't in the authorization protocol, it's in your own application logic deciding which customer's session is allowed to see which cached Slack message, Salesforce record, or Google Workspace file.

The pattern to test for is a cross-tenant version of a classic Insecure Direct Object Reference: does an API call or a background job ever determine which customer's data to return based on an identifier that arrived in client-controlled input (a request parameter, a webhook payload field) rather than being derived server-side from the authenticated session. A shared caching layer that keys on the wrong identifier, a webhook handler that trusts a tenant ID embedded in the payload instead of validating it against the signed request's origin, or a background sync job that processes multiple customers' data in the same worker without hard isolation between them are all realistic paths for Company A's connected Slack workspace or Salesforce records to leak into Company B's session. A vulnerability assessment or audit that only tests your own login boundary will miss this category entirely, because the vulnerability doesn't live at the login page. It lives in the plumbing between your database and the third-party API client.

Webhooks: the third-party access risk running in the other direction

Most of what gets discussed around SaaS integrations focuses on the outbound side, your application calling Google Workspace, Salesforce, or Slack's API using a token. The inbound side deserves equal testing. Slack, Salesforce, and Google Workspace all push events to your application through webhooks, and every one of those endpoints is a piece of your attack surface that an unauthenticated party can attempt to reach directly.

A proper assessment verifies that every webhook handler checks a cryptographic signature (Slack's signing secret, Salesforce's shared key, or the equivalent for whichever platform you're integrated with) before trusting the payload, rather than relying on the request simply arriving at the expected URL. It should also check for replay protection, since a captured, validly signed webhook payload can often be resent indefinitely unless timestamps are checked and reused. And because webhook payloads frequently trigger internal lookups (fetching a related record, triggering a downstream job), the handler itself needs the same injection and server-side request forgery testing as any other endpoint that accepts external input and acts on it.

Why your customers' security teams will ask about this before enabling it

An integration that requests access to a customer's Google Workspace or Salesforce data doesn't get evaluated by the person who wants the feature. It gets evaluated, or should be, by whoever manages that customer's third-party risk, and enterprise buyers increasingly ask for evidence before flipping on an integration that touches their CRM or their inbox, not just an assurance that it's secure. Being able to hand over a recent, dated vulnerability assessment or audit report scoped specifically to the integration, not a generic compliance letter covering your whole platform, is often the difference between an integration that gets approved in a week and one that stalls in a security questionnaire for a quarter. This is also the practical argument for testing before launch rather than after a customer asks: the companies large enough to run a real vendor security review are exactly the companies whose data footprint makes a token compromise most expensive if something does go wrong.

What a scoped assessment actually looks like before launch

A vulnerability assessment or audit ahead of a major integration launch should cover the external surface first: the OAuth callback and redirect handling, the webhook endpoints, and a review of exactly which scopes are requested and why. That's the right instrument for pre-launch coverage because it's fast to scope and doesn't require deep internal access to start producing evidence.

Penetration testing goes further, and for an integration specifically, it should include authenticated testing with real test accounts across more than one simulated tenant, attempting the exact cross-tenant access scenarios described above rather than just confirming the login page holds up. That's the only way to actually validate account isolation rather than assume it from the architecture diagram. A pentest scoped this way also has room to attempt token exfiltration through error paths and logging, and to test whether webhook signature validation actually rejects a forged or replayed request rather than just being present in the code and never actually enforced.

Neither of these is a one-time exercise. Integrations expand after launch: new scopes get added for new features, new webhook subscriptions get wired up, and the platforms themselves change their own requirements over time, the same way OAuth's Implicit Grant went from acceptable to deprecated to removed within a few years. A quarterly vulnerability assessment or audit is the right cadence for catching that drift before it becomes a production incident, because a one-time pre-launch review only reflects what the integration looked like on launch day, not what it looks like eight scope changes later. Ceron runs this on a no findings, no fee basis at every tier, the initial pre-launch audit, an extended penetration test into authenticated and multi-tenant scenarios, and the recurring quarterly assessment that catches scope creep as the integration grows, so testing an integration properly doesn't require guessing at a budget before you know what needs testing.

A pre-launch checklist worth working through line by line

Before flipping on a major integration for customers, every item below should have a clear, specific answer, not a general sense that it's probably fine. Every requested OAuth scope maps to a named feature, with no leftover permissions nobody can account for. The Authorization Code Grant with PKCE is in use everywhere, and the Implicit Grant is not in use anywhere. Redirect URIs are strictly allowlisted with exact matches, not wildcard patterns or unvalidated parameters. Access and refresh tokens are encrypted at rest and never appear in application logs, error trackers, or debug output. Refresh tokens are sender-constrained or rotated on every use. Disconnecting the integration actually calls the provider's revocation endpoint, not just a local database delete. Tenant identity is always derived server-side from the authenticated session, never trusted from client-controlled input or a webhook payload field. Every webhook handler verifies a cryptographic signature and rejects replayed requests. And the whole list gets checked again on a recurring cadence, not just once before launch.

The bottom line

A SaaS integration into Google Workspace, Salesforce, or Slack asks customers to extend trust past their own perimeter and into yours, and OWASP's OAuth guidance exists precisely because that trust relationship fails in specific, well-documented ways: overscoped tokens, deprecated flows still running in production, tokens sitting unencrypted in logs, and tenant boundaries that don't actually hold under a cross-account request. The Drift breach didn't reach 700-plus organizations because of a single dramatic exploit. It reached that scale because a set of ordinary integration mistakes, the kind a scoped vulnerability assessment or audit is built to catch, went untested long enough for an attacker already inside the vendor's environment to make full use of them.