I85PREP
⌘ K
CCAS study materials
CCAS study resources

Partner API Credential Leak and Verbose Errors

CCAS · Put your knowledge to work in context.

All case studies

Partner API Credential Leak and Verbose Errors

A logistics company exposes a partner API on AWS API Gateway. Partners authenticate with OAuth 2.0 client credentials; tokens are issued by an internal authorization server and are valid for 24 hours. The API returns JSON with detailed error messages, including stack traces and SQL fragments, to help partners debug. Last month a partner's client secret leaked from a mobile app binary; an attacker used the token from a hosting provider ASN to scrape shipment statuses for 12 hours before rate limits triggered. The API has a fixed rate limit of 1,000 requests/minute per token. There is no request schema validation; a fuzzing test found a 500 error that exposed an internal hostname. The company has 300 partners and wants to keep integration simple.

1. Prioritize the controls you would implement to reduce the impact of a leaked partner credential, explaining why each matters.

Read the worked answer

Priority order:

  1. Revoke and rotate the leaked secret and tokens. Without this, other controls only slow the attacker. Add an admin API to revoke all tokens for a client and rotate client secrets without downtime using two-secret rotation.
  2. Shorten token lifetime. 24-hour client-credentials tokens are too long for a scrapable API. Reduce to 5–15 minutes; clients can request new tokens. This limits the window after a leak.
  3. Bind tokens to the client. Use mutual TLS or DPoP so a stolen bearer token cannot be replayed from another host. If partners cannot support mTLS, DPoP is lighter but still requires client support; phase it in.
  4. Per-client rate limits and anomaly detection. Replace the fixed 1,000/min per token with per-client quotas, and alert on a sudden change in ASN, geography, user-agent, or request pattern. The fixed limit did not stop 12 hours of scraping because it was too high and not behavior-aware.
  5. Scope minimization. Partners should get only the shipment scopes they need; a leaked token should not expose all endpoints.
  6. Secret hygiene: scan mobile binaries and repositories for client secrets; never embed a client secret in a mobile app; use a backend-for-frontend.

Reasoning: controls 1–2 reduce impact now; 3–5 reduce likelihood and blast radius; 6 prevents recurrence.

2. How would you redesign error handling and input validation without breaking partner integrations?

Read the worked answer

Redesign without breaking partners:

  • Adopt RFC 7807 Problem Details with stable type, title, status, detail, and a correlationId. Return generic messages for 5xx and never include stack traces, SQL, hostnames, or internal paths.
  • Validate requests at the gateway against an OpenAPI schema: types, lengths, enums, required fields, and body size. Reject invalid input with 400 and a machine-readable error list before it reaches the backend.
  • Distinguish client errors from server errors: 4xx for validation and authentication, 5xx for internal faults with only a correlation ID. Log the detailed exception server-side with the same ID.
  • Version and communicate: introduce the new error format under a new API version or with a deprecation window; publish a migration guide and sandbox. Partners relying on the old verbose errors need time to adapt.
  • Add WAF and fuzzing to catch the 500 hostname leak and similar issues in CI.

Trade-off: less verbose errors can slow partner debugging; the correlation ID and partner support portal replace the leaked detail.

3. What should partner offboarding include beyond disabling the OAuth client?

Read the worked answer

Partner offboarding beyond disabling the OAuth client:

  1. Revoke all active access and refresh tokens, and rotate the client secret so a copied secret cannot mint new tokens.
  2. Remove the client from any IP allowlists, mTLS trust stores, or private API Gateway resource policies.
  3. Delete or disable associated API keys, webhook signing secrets, and SFTP or EDI credentials that were part of the integration.
  4. Remove partner-specific scopes and any data-sharing permissions, including S3 bucket policies or cross-account roles created for the partner.
  5. Confirm data retention and deletion obligations; export the partner's audit logs if required.
  6. Notify the partner's security contact and internal account owner, and record the offboarding in the access review system.
  7. Monitor for residual use of the partner's client ID, old tokens, or IPs for 30 days.

Reasoning: integrations often have more than one credential; disabling only the OAuth client leaves webhook secrets or allowlisted IPs that can still be used.