Minimize data and authority

The safest sensitive record is the one you never collect. The safest administrative action is the one your product does not expose.

Every field, log line, export, token, and integration you add is something that can leak, be stolen, or be abused. Reducing stored data and powerful capabilities shrinks both the attack surface and the incident you may one day need to explain to your users.

Question every field

Ask why each piece of data exists, who owns it, and when it gets deleted:

field                why we store it           retention
email                login + receipts          account lifetime
date of birth        nobody remembers          none defined
full reset URL       "useful for debugging"    90 days in logs
last 4 card digits   support lookups           account lifetime

Two rows in that table should worry you. The date of birth has no owner and no purpose — delete the column. The full reset URL is worse, and it deserves its own story.

The reset-URL log

An analytics log stores complete password-reset URLs for debugging. Each URL contains a live reset token. The token later expires, but every log reader had account-reset authority during its lifetime. The logging pipeline, the dashboard, the third-party log vendor — all of them briefly held the keys to any account that requested a reset.

Nobody designed that. It happened because logging the full URL was the easy thing to do.

Removing the field can reduce debugging context during support work, and support will notice. Keep a safe event identifier or a token fingerprint instead of the reusable secret:

log.info('password_reset.requested', {
  user: user.id,
  tokenFingerprint: sha256(token).slice(0, 12), // correlates, cannot be redeemed
})

You can still match a support ticket to the exact reset event. You just cannot take over the account from the log.

Authority counts too

The same logic applies to what the product can do. A “delete all users” admin endpoint that no real workflow needs is pure downside: it will never help you, and it might help an attacker.

Find one sensitive value kept in a field, log, or export and document why it exists. Remove or redact it, then prove the product still supports its real task and the raw value no longer appears. Repeat the audit every few months. Data grows back.