Cloud Logging with Sensitive Data
Your app logs PII, tokens, or credentials to CloudWatch, Stackdriver, or other cloud logging services, where they persist indefinitely and are accessible to anyone with log read permissions.
How It Works
Cloud logs are often less tightly controlled than your database. They're shared with all developers on the team, ingested by third-party monitoring tools, and stored for months or years. When your app logs request bodies, headers, or debug info containing user PII, API tokens, or passwords, that data becomes broadly accessible. Log retention policies and access controls are often an afterthought.
// BAD: logging full request body which may contain passwords or tokens
export async function POST(req: Request) {
const body = await req.json();
console.log('Request body:', JSON.stringify(body)); // may contain password, token
// ... rest of handler
}// GOOD: log only safe, non-sensitive metadata
export async function POST(req: Request) {
const body = await req.json();
// Log action type and user ID only — never the actual values
console.log('Request received:', { action: body.action, userId: body.userId });
// ... rest of handler
}Real-World Example
A major fintech company discovered that their CloudWatch logs contained full JWT tokens in request headers that were being logged by their API Gateway access log format string. Anyone with CloudWatch read access — including third-party APM tools — had access to active session tokens for months.
How to Prevent It
- Audit your log statements to ensure no PII, passwords, tokens, or secrets are logged
- Use structured logging with explicit field allowlists — only log fields you've reviewed
- Configure log redaction in your logging library (Winston, Pino have redact options) for sensitive field names
- Set appropriate log retention periods — don't store sensitive logs indefinitely
- Restrict CloudWatch/Stackdriver log access to the teams that actually need it
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
S3 Bucket Public Access
criticalYour S3 bucket is publicly readable due to a public ACL, disabled Block Public Access settings, or a wildcard bucket policy — anyone on the internet can list and download your files.
Cloud Metadata SSRF
criticalYour app fetches user-supplied URLs without blocking cloud metadata endpoints like 169.254.169.254, letting attackers steal your cloud credentials via SSRF.
AWS Credentials Hardcoded
criticalAWS access keys (starting with AKIA) or secret access keys are hardcoded in your source code, giving anyone who reads the code full access to your AWS account.
IAM Overly Permissive Policy
highYour IAM policy uses Action: '*' or Resource: '*', granting far more permissions than needed and turning any credential leak into a full account takeover.