mediumCWE-312A02:2021

Sensitive Data in Emails

Sending passwords, full tokens, card details, or excessive personal data in emails exposes that data to email providers, forwarding recipients, and anyone with inbox access.

How It Works

Email is not a secure channel — it passes through multiple servers, is often indexed by email providers, and may be forwarded or backed up in plaintext. Sending a full authentication token or password reset link with an embedded token is often unavoidable, but sending actual passwords or payment data in email is never acceptable.

Vulnerable Code
// BAD: sending actual password or sensitive data in email body
await sendEmail({
  to: user.email,
  subject: 'Your account details',
  body: `Your password is: ${plaintextPassword}\nYour card ending in: ${card.number}`
});
Secure Code
// GOOD: send only a time-limited link, never the actual sensitive data
await sendEmail({
  to: user.email,
  subject: 'Reset your password',
  body: `Click to reset (expires in 1 hour): https://app.com/reset?token=${resetToken}`
  // token is single-use and expires — no raw credentials in email
});

Real-World Example

Countless startup support emails have accidentally included plaintext passwords in 'welcome' or 'password reset' emails — indicating that passwords were stored in plaintext in the database. This is both a direct vulnerability and an indicator of deeper security problems.

How to Prevent It

  • Never send plaintext passwords, full tokens, or payment data in emails
  • For password resets, send a time-limited link with a single-use token — not the new password
  • For account summaries, show only the last 4 digits of card numbers and masked email addresses
  • Audit your email templates for any field that could contain sensitive user data

Affected Technologies

Node.js

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities