Hidden in Plain Sight: XHack AI Found a Live Email-Provider Key Baked Into a Survey Tool's JavaScript

Executive Summary

A small customer-feedback SaaS, referred to throughout this document only as Redacted, engaged XHack for a short AI-assisted security audit ahead of a marketing push expected to grow their traffic. The product lets businesses embed a survey widget on their own sites and emails a short "thanks for your feedback" confirmation to each respondent.

While parsing the application's compiled front-end JavaScript, XHack AI flagged a high-entropy string embedded in one of the bundle's configuration modules. It matched the format of a server-side token for a well-known transactional email provider, referred to here only as the email provider. The token was being used directly from the browser to trigger confirmation emails, which meant it was shipped, in full, to every visitor who loaded the page.

XHack AI surfaced the string within hours of starting, and the XHack analyst team confirmed the token was live using a single read-only call to the provider's account endpoint — sending no email of any kind. The token authorised sending mail from the client's own verified sending domain. The client rotated it the same day.

No email was ever sent during the assessment, and no recipient data was accessed.

Client Background

The client is a ten-person SaaS company. Their product is embedded on their customers' websites, so their JavaScript runs in front of a large and untrusted audience by design. The confirmation-email feature had been added early in the product's life to make the widget feel responsive and polished.

For commercial reasons the client cannot be identified beyond this description.

Scope of the Engagement

• Target: the production web application, its public JavaScript assets, and the authenticated API
• Approach: grey-box, with one standard customer account and permission to analyse the publicly served front-end assets
• Out of scope: the email provider's own infrastructure, the marketing site, and third-party analytics
• Rules of engagement: any discovered credential was to be validated with the least intrusive possible check and never used to perform a real send

Discovery: How XHack AI Found It

XHack AI treats an application's shipped front-end as an attack surface in its own right, not just a route to the API. As part of mapping that surface, it retrieved every JavaScript chunk the application served and scanned each for the patterns and entropy characteristic of embedded secrets.

Two things made the finding clean and unambiguous:

1. A minified chunk contained a string with the exact prefix and length of the email provider's server tokens.
2. The application had also deployed the corresponding source map (.js.map) to production. XHack AI used it to de-minify the chunk back to readable source, where the string appeared in a configuration module under a clearly named constant and was passed straight into a browser-side call to the provider's send API.

In sanitised form, the reconstructed code read like this:

// Reconstructed from the production source map (sanitised)
const EMAIL_PROVIDER_TOKEN = "srv_live_[redacted-high-entropy-token]";

async function sendThanksEmail(recipient) {
  await fetch("https://api.[email-provider].example/v1/send", {
    method: "POST",
    headers: { "Authorization": `Bearer ${EMAIL_PROVIDER_TOKEN}` },
    body: JSON.stringify({ to: recipient, template: "survey-thanks" }),
  });
}

The token was a server credential doing a server's job from inside the browser. Anyone who opened developer tools, or simply downloaded the public bundle, held the same credential the application did.

Why This Happened

The confirmation email needed to be sent when a respondent finished a survey. The simplest way to make that happen during early development was to call the provider directly from the front-end, which requires the token to be present in the front-end. That token is a server secret: it authorises sending mail as the client's verified domain and reading the account's sending activity. It was never meant to leave the server.

Two compounding mistakes turned a bad-but-common pattern into an easy find. The secret was hard-coded into client-side code rather than kept behind a server endpoint, and the production build shipped source maps, which removed even the minor obstacle of minification and handed a readable, well-labelled copy to anyone who looked.

Technical Breakdown

Property	Detail
Vulnerability Class	Hard-coded / Exposed Secret in Client-Side Code
OWASP Top 10	A07:2021 Identification and Authentication Failures
CWE	CWE-798 Use of Hard-coded Credentials; CWE-312 Cleartext Storage of Sensitive Information
CVSSv3 Score	8.2 (High)
Attack Vector	Network
Authentication Required	No (token served to every visitor)
Privilege Required	None
User Interaction Required	None
Impact	Ability to send email from the client's verified domain; read the provider account's sending activity

Triage and Confirmation

XHack AI flagged the finding for human review at High severity. The XHack analyst team confirmed it with the lightest possible touch:

1. Validated the token was live using a single authenticated read-only request to the provider's account-information endpoint. The call returned the client's account details, confirming the token was active and belonged to the client. No email endpoint was touched.
2. Determined the token's authority from the provider's documented scope for that token type: sending on behalf of the account's verified domains and reading message/activity logs.
3. Confirmed the exposure was public by loading the token from the production bundle in a clean browser session with no authentication, exactly as any visitor would.
4. Stopped immediately and disclosed to the client, recommending rotation as the first action before any further analysis.

The finding was confirmed valid, trivially reachable, and High in severity.

Impact Assessment

Confidentiality

• Read access to the email provider account's sending activity and logs, which can reveal recipient addresses and messaging patterns.

Integrity and Trust

• The most serious impact. The token authorised sending mail from the client's verified sending domain. An attacker could send convincing phishing directly from the company's real address — passing SPF and DKIM because the mail genuinely originated from the authorised provider — against the company's own customers.

Financial and Reputational

• Abuse of the account for bulk sending would incur cost and risk the client's sending reputation and domain being blocklisted, which for an email-dependent product is an existential operational problem.

Regulatory Exposure

• Recipient email addresses are personal data. Unauthorised access to the sending logs, or misuse of the account to mail respondents, could trigger notification obligations under GDPR.

Remediation

Immediate (Same Day)

• Rotate the token at the email provider, invalidating the exposed credential before anything else.
• Remove the credential from the front-end entirely. Confirmation emails are now sent by a small server endpoint that holds the token in server-side configuration; the browser calls that endpoint, never the provider.
• Stop shipping source maps to production, or restrict them to an authenticated error-monitoring service rather than serving them publicly.

Short-Term (Within Days)

• Scan the rest of the front-end and the repository history for any other embedded secret. One additional analytics key was found in the bundle and rotated; nothing was found in Git history beyond the same token.
• Move all secrets to server-side environment configuration, and adopt a clear rule that no secret is ever referenced from client-side code.
• Scope the new server token to the minimum needed — sending only, with no broader account access than the confirmation email requires.

Recommended Longer-Term Controls

• Add automated secret scanning to CI, failing any build that introduces a high-entropy credential into client-side code or commits one to the repository.
• Establish credential rotation as routine, so an exposed secret is a quick, rehearsed response rather than an emergency.
• Re-test the shipped bundle on a cadence, since front-end secrets tend to creep back in whenever a feature needs to talk to a third-party service quickly.

Outcome

The client rotated the token within two hours of disclosure, moved the confirmation-email flow behind a server endpoint the same day, and disabled public source maps in the next deploy. A re-test by XHack confirmed that the production bundle no longer contained the token or any other secret, that source maps were no longer served, and that the new server token could not be recovered from anything the browser received.

No email was sent from the account during the assessment, and the provider's activity log showed no unauthorised sends before remediation. The client's founder noted that the direct-from-browser send had been a deliberate early shortcut that "was always going to be replaced" and simply never had been.

This case is a good illustration of why XHack AI reads the parts of an application that a UI-focused test walks straight past. A shipped JavaScript bundle is public, and everything in it — every string, every configuration constant, every leftover source map — is readable by anyone. Exhaustively parsing that surface for exposed secrets is tedious, mechanical work that an autonomous agent does quickly and without missing a chunk. XHack AI found this one in under a day.