This lesson's interactive features are locked, please to keep using them

Personally Identifiable Information

Personally identifiable information (PII) identifies or can be linked to a real person. Names, email addresses, street addresses, and uploaded document names can all qualify.

The thing about PII is that it's useful to attackers even outside your application. It can fuel phishing, identity theft, stalking, account recovery attacks, and social engineering. Unlike a password or API key, a person can't exactly rotate their home address or SSN after a breach.

Protect the Stored Value

Bearly Secure needs shipping details to fulfill an order and show authorized support staff the delivery information. That makes deletion or one-way hashing impractical, but it doesn't justify leaving the data in plaintext.

Serialize the structured shipping details, encrypt them with the shared keyring, and store only the versioned ciphertext. Decrypt them only at an authorized use point. Keep unrelated operational notes free of copied PII.

Prefer Stable IDs

Identifiers like userId, orderId, and uploadedFileId usually provide enough context to investigate an event without copying the customer's email, shipping address, or filename into your logs.

For example, this event keeps its diagnostic value:

{
  "event": "checkout_completed",
  "userId": 42,
  "orderId": 108,
  "totalCents": 2499,
  "shippingAddress": "[REDACTED]"
}

An authorized employee can use the IDs to retrieve the relevant record through a controlled system, but an attacker who steals just the log doesn't get the customer's identity or address.

These IDs are pseudonymous, not truly anonymous. Anyone with access to the application database can probably still connect them back to a person.

Assignment

Bearly Secure already routes shipping details through intentionally insecure storage transforms and keeps them out of operational notes. Encrypt those shipping details and extend the centralized log redaction policy.

In internal/orders/shipping.go, implement EncryptShippingDetails by serializing the complete structure and encrypting it with the shared keyring.
Implement DecryptShippingDetails by decrypting and parsing the payload. Reject malformed structures or missing fields.
In internal/logging/logger.go, centrally redact email addresses, shipping fields, and original upload names while preserving stable IDs and useful non-sensitive metadata.
Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.