A city permitting API returns bearer tokens to mobile clients. A developer proposes logging every Authorization header to CloudWatch Logs for easier debugging. What should the team do?
Select an answer to reveal the explanation.
Short Explanation
Bearer tokens are keys to the city vault—ship them only over HTTPS and keep them out of logs. Dumping Authorization headers into CloudWatch is a leak waiting to happen. Debug with redacted IDs, not live secrets.
Full Explanation
Bearer tokens returned to mobile clients for a city permitting API are credentials and must be handled like secrets. Require HTTPS for all token transit and never write Authorization headers or raw bearer tokens to CloudWatch Logs, world-readable buckets, or support tickets. Prefer request IDs, hashed subject identifiers when necessary, and structured authentication outcomes for debugging so log systems do not become a warehouse of reusable session secrets.
Logging full Authorization headers into an unencrypted S3 bucket for ninety days multiplies breach impact if those logs leak. Switching the API to plain HTTP so tokens are easier to capture in packet traces intentionally weakens transit security. Embedding long-lived IAM access keys in the mobile app instead of short-lived bearer tokens is a worse secret-distribution strategy than proper OAuth tokens.
Exam caveat: treat tokens like passwords across logs, APM tools, and analytics pipelines; enable redaction in HTTP logging middleware by default. Operational check: after a test login and API call, search CloudWatch Logs Insights for “Bearer” and “Authorization,” confirm absence, verify the API is HTTPS-only, and rotate any token that was previously logged during a debugging session.