📌 API Bug Bounty – Real‑World Vulnerabilities

1. Response Leakage via Implicit Broadcast (Shopify Android)

Issue: The Shopify Android client used an unprotected broadcast (com.shopify.service.requestComplete) to pass network responses intra‑app. Any app on the device could register a receiver and steal access tokens, cookies, and response bodies.

Impact: Account takeover, session hijacking.

Fix: Use protected broadcasts with permissions or local broadcasts (LocalBroadcastManager).

2. OAuth Authorization Code Not Revoked After Access Revocation (Vimeo)

Issue: When a user revoked the application, access tokens were invalidated, but previously issued authorization codes remained usable. An attacker could exchange a saved code for a new access token even after revocation.

Impact: Persistent access after user removal.

Fix: Revoke all codes when access is revoked; implement short code lifetimes.

3. Disabled Agent Account Still Usable via Access Token (Zopim)

Issue: An agent account was disabled by the owner, but the access token remained valid. The attacker could continue using the token to create new accounts.

Impact: Privilege escalation, account persistence.

Fix: Invalidate all tokens when account is disabled.

4. Missing Authorization Checks (Fabric.io / MoPub)

Issue: A member’s access token could be used to delete an organization’s app (admin‑only action). No proper role verification on the API endpoint.

Impact: Data loss, application deletion.

Fix: Enforce role‑based access control on every endpoint.

5. Race Conditions in OAuth Token Generation

Issue: By sending multiple concurrent requests to the token endpoint with the same authorization code, an attacker could obtain multiple valid access/refresh token pairs. Revoking one pair did not invalidate the others.

Impact: Persistent access after revocation.

Fix: Use idempotency keys or lock the authorization code after first use.

6. API Rate Limit Bypass

Issue: Several APIs allowed bypassing rate limits by using different IPs, rotating parameters, or exploiting low‑granularity limits.

Impact: Brute‑force, resource exhaustion.

Fix: Implement distributed rate limiting (e.g., Redis + sliding window) and keyed by user/session.

7. Timing Attack in HMAC Comparison (Shopify Python API)

Issue: The fallback string comparison (hmac_calculated == hmac_to_verify) used short‑circuit evaluation, allowing timing‑based brute force of the HMAC.

Impact: Potential signature forgery.

Fix: Always use constant‑time comparison (hmac.compare_digest).

8. API Key Exposure (Starbucks Turkey)

Issue: A hardcoded Basic Auth token in the mobile app allowed full access to the internal API documentation and all GET endpoints without authentication.

Impact: Unauthorised access to sensitive user data.

Fix: Never hardcode credentials; use server‑side tokens with expiration and scope.

📚 Lessons Learned

• Always validate authorization on every API call (not just authentication).
• Revoke all derived tokens (codes, refresh tokens) when access is revoked.
• Use constant‑time comparison for cryptographic secrets.
• Implement proper rate limiting with distributed state.
• Do not rely on client‑side security (broadcasts, hardcoded keys).