Identifying Sensitive Data in Code

The Hidden Border Crossing

When you interact with external AI tools—whether it’s a chat interface or an IDE extension—you are essentially sending snippets of your codebase to a third-party server. If that snippet contains sensitive data, you have just created a security breach. This lesson focuses on identifying exactly what constitutes 'sensitive data' so you can strip it out before hitting send.

The Three Pillars of Sensitive Data

In our engineering workflow, sensitive data generally falls into three specific categories. First, secrets and credentials, which are the keys to our kingdom. Second, customer data like PII and PHI, which are legally protected. And finally, our proprietary business logic—the secret sauce that makes our software unique.

Secrets: The Keys to the Kingdom

Secrets are non-negotiable. If leaked, an attacker can impersonate our services or access our infrastructure directly. This includes API tokens and live keys. It also covers database strings containing usernames and passwords, and any private certificates or keys used for authentication.

PII and PHI: Customer Privacy

Personally Identifiable Information and Protected Health Information are subject to strict legal requirements. While names and emails are obvious, remember that technical identifiers like IP addresses and session tokens are also considered PII under regulations like GDPR.

Spot the Vulnerability: .env

Let's put this into practice. Imagine you want to ask an AI to generate a Dockerfile for this configuration. Click the specific lines in this .env file that must be redacted before you paste it into the prompt. Actually, this line is just configuration metadata like a port or environment name. It's generally safe to include. Correct. This line contains a live production secret or an internal credential that should never leave your machine.

Audit: The JSON Payload

You are debugging a data transformation and need to paste a sample record. Click the fields containing PII that must be scrubbed. Exactly. Even a single record with a real name, email, or address is a policy violation. This field is safe. Internal IDs like order numbers or SKUs are generally acceptable for debugging logic.

The Vibe Coding Risk

In 'vibe coding'—pasting full logs to fix errors quickly—it's easy to leak active sessions. Examine this log and click the most dangerous lines. Spot on. The Cookie and Authorization headers contain active session tokens. Anyone with access to the AI's history could hijack a live user session.

Recap: The Public Square Test

Before you paste, ask yourself: 'Would I be comfortable posting this on a public forum like StackOverflow?' If the answer is no, redact it. Use synthetic data for testing and consider automated tools like Microsoft Presidio to scrub PII locally before it ever crosses the wire.