The Qantas Breach: 5.7 Million Records Lost Through a Third-Party Integration

Qantas's core systems weren't breached. Their payment infrastructure was fine. Their reservations database was intact. A security team at an airline with 100+ years of operational history didn't make some glaring obvious mistake in their own code.

A third-party system they connected to got compromised. That third-party had access to 5.7 million customer records. And because of that single integration, Qantas had to notify millions of passengers that their names, email addresses, phone numbers, and frequent flyer numbers were in someone else's hands.

This is the third-party integration security breach pattern, and it's quietly becoming one of the most common ways large-scale data exposures happen. The attack surface isn't your code. It's everyone you've handed a key to.

What actually happened

In mid-2025, Qantas disclosed that a third-party platform integrated with Salesforce — used to manage customer data — had been compromised. The exposed records included:

• Full names
• Email addresses
• Phone numbers
• Frequent flyer membership numbers
• Contact details

Approximately 5.7 million customers were affected. Payment card data and passport information were not exposed, which matters — but names and frequent flyer numbers combined with email addresses is still plenty for targeted phishing and account takeover attempts.

The mechanism wasn't exotic. The third-party vendor had been granted API access to Qantas's Salesforce environment. When that vendor's systems were compromised, the attacker used the vendor's existing, legitimate credentials to pull customer data. No zero-day required. No brute force. Just a valid API token with too much access.

This is consistent with the pattern OWASP identifies as Supply Chain attack vectors, where a trusted third-party becomes the entry point into your system. It's also reflected in the Verizon 2025 Data Breach Investigations Report, which found that third-party involvement in breaches increased by 15 percentage points year-over-year.

The problem: you don't control your integration's security posture

Here's the part developers don't think about when they're wiring up a Salesforce Connected App or adding a HubSpot webhook.

When you grant a third-party access to your data, you're not just trusting their product. You're trusting:

• Their internal credential management
• Their employee access controls
• Their incident response procedures
• Every dependency they run
• Every contractor who touches their systems

If any of that chain is weak and your integration has broad access, your users pay for it. You inherited their attack surface the moment you clicked "Authorize."

This isn't hypothetical risk. The Palo Alto Networks Unit 42 Incident Response Report 2025 found that 45% of incidents they responded to involved third-party access vectors. Not vulnerabilities in the primary org's code — access paths held by external parties.

The uncomfortable truth: your security posture is only as strong as the weakest integration you've authorized.

What "minimum privilege" looks like in practice

The Qantas breach became possible because the third-party had more access than it needed. This is overwhelmingly common. Default OAuth scopes in enterprise SaaS platforms lean toward "full API access" because that's what works with zero configuration friction. Vendors request it because it's easier. Teams grant it because they're focused on making the integration work, not on what happens when the vendor is compromised.

Minimum privilege — giving an integration only the exact permissions it needs, nothing more — is the single most effective control against this class of breach. If the third-party had read-only access to a specific subset of contact fields instead of broad CRM access, the breach scope would have been dramatically smaller.

Here's what this looks like concretely.

Salesforce Connected App scopes:

// BAD: Full API access — the default, and far too broad
scope: "api refresh_token"
 
// GOOD: Read-only on the specific objects the integration actually needs
scope: "api:Contacts:read api:Accounts:read refresh_token"

The api scope in Salesforce grants full read/write access to all objects the connected user can access. That's not what a reporting integration or a marketing sync needs. Narrow it.

Stripe restricted keys:

// BAD: Using a full secret key for a third-party analytics integration
Authorization: Bearer sk_live_abc123fullsecretkey...
 
// GOOD: Create a restricted key scoped to exactly what the integration reads
// Stripe Dashboard → Developers → API Keys → Create restricted key
// Grant: charges:read, customers:read — nothing else
Authorization: Bearer rk_live_restrictedkeyabc...

Stripe has had restricted key support for years. Most teams don't use it. The full secret key gets pasted into the integration because that's what the docs show and it works immediately. The restricted key takes five extra minutes to set up and limits blast radius to a fraction of what a full key exposure would cause.

The same principle applies everywhere: HubSpot private apps let you scope to specific CRM objects. SendGrid API keys can be restricted to specific actions. Twilio subaccounts isolate access. The controls exist. They're just not the path of least resistance.

A 5-step audit for developers who use Salesforce, Stripe, HubSpot, or any SaaS integration

Most teams have no current inventory of what third-party systems can access their data right now. That's the starting point. Here's how to get from zero to defensible in under two hours.

Step 1: List every third-party with access to your data

Go through your connected apps, OAuth authorizations, webhook configurations, and API key issuances. Include:

• CRM integrations (Salesforce, HubSpot)
• Payment processors (Stripe, PayPal)
• Email/SMS providers (Resend, SendGrid, Twilio)
• Analytics platforms
• Support tooling (Intercom, Zendesk)
• Any contractor-built integrations

If you don't have this list, building it is the first task. You can't manage access you don't know exists.

Step 2: Verify minimum required scope for each

For each integration on your list, answer: what does this actually need to do its job? Then check whether the current permissions match that. In practice, most integrations will be over-privileged. The goal isn't to fix everything today — it's to identify the gaps.

Step 3: Check for hardcoded credentials in your repo

This is where it gets uncomfortable. Third-party API keys and tokens get hardcoded into environment config files, committed accidentally, or left in comments "temporarily." A scan of real repositories consistently turns up credentials for connected services — not just app secrets, but Salesforce refresh tokens, HubSpot private app keys, Stripe secret keys.

# Quick check: search your repo history for common credential patterns
git log --all -p | grep -E "(sk_live|rk_live|Bearer [a-zA-Z0-9]{20})" | head -20

This won't catch everything, but it will tell you quickly whether you have an obvious problem. A proper scan — one that covers all 200+ credential patterns across your full commit history — takes a few minutes with Data Hogo's repo scanner.

Step 4: Verify you'd know if a third-party accessed data unexpectedly

Integration-level logging is rare. Most teams log application events but don't monitor what connected services are doing with delegated access. At minimum, you should:

• Enable Salesforce Connected App access logs if you use Connected Apps
• Enable Stripe webhook event logs for any third-party webhook consumer
• Review your cloud provider's API access logs quarterly

If an integration started pulling 5.7 million records at 2am, would you get an alert? If the answer is no, that's a gap.

Step 5: Confirm you can revoke access for each integration in under 5 minutes

When an incident happens, speed matters. Walk through the revocation process for each integration now, before you need it under pressure. Know where to go in each platform to invalidate the credentials. Document it.

For OAuth-based integrations, this usually means revoking the Connected App authorization in the provider's admin panel. For API keys, it's rotating or deleting the key and issuing a new restricted one. If you can't figure out how to revoke access in under 5 minutes, that's a problem to fix today.

The inherited attack surface you're not thinking about

There's a framing that helps make this concrete: every integration you add extends your attack surface into territory you don't control.

When you connect Salesforce to a third-party analytics tool, you're not just using a feature. You're creating a path where that analytics vendor — and anyone who compromises them — can reach your customer data. The path exists as long as the integration exists, regardless of whether you actively think about it.

This is what makes the Qantas breach a useful case study rather than a cautionary tale about some exotic attack. Nobody did anything dramatically wrong. Qantas connected a vendor to Salesforce. The vendor got compromised. The attacker used the vendor's credentials. 5.7 million records walked out the door.

Your app probably has 5 to 15 active third-party integrations right now. Each one is a door. The question isn't whether you've locked your own doors — it's whether you know what you handed out keys to, and whether those keys open more rooms than they need to.

Third-party integration security isn't a "big company problem." If you're building anything that stores user data and connecting it to SaaS tools — which describes most production apps today — the same exposure path applies. The only variable is scale.

TL;DR

• Qantas lost 5.7M customer records — names, emails, frequent flyer numbers, phone numbers — through a Salesforce-connected third-party integration, not a breach of their own systems.
• The third-party had overprivileged access. When the vendor was compromised, that access was used to pull customer data.
• Every integration you authorize inherits its security posture into your attack surface. If the vendor is weak, your users pay for it.
• Minimum privilege is the most effective control: grant integrations only the exact scopes they need, not "full API access."
• Most teams have no current inventory of what third-party systems can access their data — building that list is step one.
• Hardcoded third-party credentials in your repo history are a real and common risk. Check it.
• If you can't revoke access to a critical integration in under 5 minutes, fix that before you need to.