Author: Syed Jan Muhammad Zaidi 

Title: Founder Darkanon

X: @th3_d4rkninj4 

LinkedIn: syed-jan-muhammad-zaidi

Summary

During an authenticated penetration test, I discovered a Base64-embedded Qualaroo API key in the browser-facing code. After decoding the string I confirmed the credential format with Qualaroo documentation and used it to call the Qualaroo API. The key allowed listing surveys and dumping responses, which included IP addresses, user agents and free-text answers. The secret was in client-side code and therefore trivially accessible to any attacker who inspects the bundle or page source.

In the app source I found a config object similar to:

qualaroo: {
 cus_api_key: "QmFzZTY0RW5jb2RlZEtleVN0cmluZw=="
}
 

Steps I performed

1. Extracted and Base64-decoded the value.
2. Confirmed the decoded token format matched Qualaroo’s documented key shape.
3. Used the key in a non-destructive read-only call to enumerate survey responses:

curl -u "77XX:ApiKey" "https://api.qualaroo.com/api/v1/nudges/<survey_id>/responses.json" | jq -r

The API returned survey objects and response payloads such as:

• response id and timestamp
• page / referrer where the nudge fired
• anon_visitor_id and ip_address
• user_agent
• responses
   

Why this is dangerous?

• Client-side secrets are public by default. Anything shipped to the browser is effectively public. Base64 encoding is obfuscation, not security.
• Survey responses frequently contain PII or contextual information that can be abused (emails, comments with account references, internal notes).
• If the key allows write operations an attacker can manipulate content, inject malicious links, or delete data.
• Many teams assume third-party widgets are “safe” because they use vendor services; but an exposed vendor credential lets an attacker bypass your application’s access control entirely.

Proof-of-Concept (PoC) :

• Decode Base64 locally:

echo "QmFzZTY0RW5jb2RlZEtleVN0cmluZw==" | base64 -d

• Test endpoint with decoded credential:

curl -v -u "77XX:DECODED_KEY" "https://api.qualaroo.com/api/v1/nudges/<survey_id>/responses.json" | jq -r

• Inspect results for number of survey objects, response counts, and fields that contain PII.
• Document/attach evidence screenshots and sanitized sample responses for the client report.

Immediate remediation (what to do right now)

1. Revoke and rotate the key immediately
   • Treat the key as compromised. Revoke it in the Qualaroo console and create a new key with minimal scope.
2. Remove any client-side embedding
   • Remove the key from JS bundles, HTML, or any asset that ships to the browser.
3. Search and purge
   • Scan codebase, build artifacts, deployment buckets, and commit history for the key or similar keys.
4. Audit vendor logs
   • Review Qualaroo logs for suspicious downloads or bulk exports. Collect evidence for breach assessment.
5. Notify stakeholders
   • Follow your incident response process. If PII is exposed, follow legal and compliance notification requirements.
6. Temporary mitigation
   • If you cannot rotate immediately, restrict the key (IP/domain restrictions) if the vendor supports it.

Secure design and long-term remediation

Move keys to server side

Never embed permanent or long-lived API keys in client-side code. Have your backend call the third-party API using keys stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.). The frontend should never hold such secrets.

Vendor-side restrictions and least privilege

• Use least-privilege keys (read-only where possible).
• Use short-lived tokens or OAuth flows if vendor supports them.
• Use IP/domain allowlists and scope restrictions offered by the vendor.

Secrets hygiene in development lifecycle

• Add secret scanning in CI (pre-commit hooks and pipeline checks). Tools: git-secrets, trufflehog, detect-secrets and commercial SaaS scanners.
• Fail builds if keys are detected in code or artifacts.
• Use environment-specific secrets not checked into source (CI secrets, environment variables, secrets manager).