We recently discovered an Airtable Personal Access Token leaked on the homepage of a major e-commerce platform. With it, we could have hijacked the entire site — redirecting users to phishing pages, altering product listings, or silently defacing the brand. The vulnerability report was rejected as "Out of Scope". Here's why that reasoning doesn't hold up — and why attackers won't care either.
Scope Is a Contract — Not a Security Boundary
In penetration tests and bug bounty programs, scope defines what testers are allowed to interact with. It can take many forms: a wildcard domain with carefully crafted exclusions, a small set of explicitly authorized subdomains, specific URLs or paths, or even a list of IP addresses.
These restrictions exist for good reasons. Organizations want to ensure that testing is limited to assets they actually own or control, that these systems have already been internally reviewed, and that no traffic is accidentally sent to third-party providers who may not be aware of — or tolerant toward — aggressive security testing.
All of this makes sense from a legal and operational standpoint. But it leads to a dangerous assumption: that scope somehow represents a real security boundary.
In reality, scope is a contract — not a line attackers will respect. Secrets don't stay neatly confined within it, and attackers certainly don't stop when they cross it.
Modern Web Applications Don't Have Clean Boundaries
Modern web applications are no longer isolated systems running on a single domain. They are assemblies of services, stitched together to deliver performance, scalability, and business features.
A typical application today may rely on CDNs and WAFs at the edge, a headless CMS or backend API for content and data, and a growing number of SaaS platforms to handle analytics, payments, automation, or AI-driven features.
From an implementation perspective, this often means loading third-party JavaScript directly in the browser or making client-side requests to external APIs. Those integrations frequently require API keys, access tokens, or other credentials — and those secrets sometimes end up exposed where anyone can see them.
From the browser's point of view, all of these components form a single application.
From an attacker's point of view, the notion of scope quickly becomes blurry.
This is where friction often appears, particularly in bug bounty programs: what is technically exploitable in practice does not always align with what is contractually allowed on paper.
When Scope Collides With Reality
Recently, SecretsBuster detected an Airtable Personal Access Token leaked directly on the homepage of an
in-scope web application. To preserve confidentiality, we'll refer to the target as
https://mytarget.com — but we're not talking about a hobbyist's side project here. This
was a well-established e-commerce platform with millions of monthly visitors, a recognized brand, and
an active bug bounty program on a major platform.
Airtable Personal Access Tokens are not meant to be public. According to Airtable's own documentation, these tokens can grant powerful permissions — far beyond what should ever be accessible to an anonymous user visiting a website.
Using this exposed token, we demonstrated a realistic and low-effort attack scenario. We were able to modify application content and redirect all application paths to external websites of our choice. This opened the door to phishing campaigns, service disruption, and significant brand damage.
Crucially, the impact was entirely on the in-scope web application.
And yet, the report was ultimately rejected as "Out of Scope". The justification was that exploitation required sending API requests to Airtable, a third-party service hosting the data.
Ambiguous Responsibility, Real Risk
If we take a step back, the situation is clear.
A secret was exposed directly within an in-scope application. That secret granted control over how the application behaved for its users. The resulting impact affected only the in-scope asset. The only "out-of-scope" element was the infrastructure involved during exploitation.
This naturally raises uncomfortable but necessary questions for security teams.
If a secret is leaked client-side, does the physical location of the backend really matter? If a frontend is little more than a thin layer on top of a headless CMS, is that CMS suddenly out of scope? And should attackers be expected to stop their exploitation simply because a contractual boundary has been crossed?
In practice, they never do.
How SecretsBuster Approaches the Problem
At SecretsBuster, we don't treat scope as a proxy for risk. Instead, we focus on how real attackers operate.
Our objective is straightforward: identify exposed secrets before they are discovered and abused in the wild.
To do that, we combine passive analysis with carefully targeted active detection, always keeping intrusiveness to a minimum. We inspect client-side assets and third-party integrations in the same way an attacker would, looking for credentials that silently grant access to critical backend services or put users at risk.
This approach allows us to uncover API keys and tokens leaked in frontend code, secrets embedded in third-party scripts, and credentials that create unexpected trust relationships across your application stack — all while remaining low-noise and safe for production environments.
Because when something goes wrong, no customer will accept "it was out of scope" as an explanation. They'll only care that it happened — and that it could have been prevented.
Detecting these exposures before attackers do is exactly what SecretsBuster was built for.