The last two lessons moved secrets to the right place: The database doesn’t need one anymore, and the link key sits in Key Vault. A secret that’s well kept can still seep out, though, wherever it’s used. This lesson is about the ways that happens, and about the most common one: the log. At the end, the Kladde redacts addresses and personal data in its logs, a test proves it, and GitHub rejects a push containing a known key.

Where secrets seep out

Almost never is a secret stolen by someone breaking into a vault. Usually it simply lies somewhere it doesn’t belong:

  • Parameter files and tools’ local files. azd keeps parameter values in .azure/<environment>/ in plain text (lesson 3.2.6), and an .env lands in the repository with a careless git add ..
  • Pipeline logs. Pipelines mask secrets in their output, but only in the form in which they know them. A secret that a step transforms, for example to Base64 or into an address, then sits readable in the log (lesson 3.7.7).
  • Error pages. The developer error page shows the environment, headers and parts of the configuration. It belongs only in Development.
  • Logs. Addresses with a key in the query, an Authorization header, a connection string in an exception message, a whole request body “for debugging.”
  • Tickets, chats and language models. What you copy into a ticket, a chat or an AI tool then sits with its operator. A secret that a tool printed or read therefore counts as leaked, even if only an assistant saw it.
  • Screenshots and shared screens. The portal shows values on a click, the terminal keeps its history, a window with appsettings.Development.json sits in the background of a video.
  • Git history. What was once committed and pushed is in every clone, in every fork and in the platform’s events.

The Kladde’s house rules sum it up in one sentence: no secret in code, parameters, .env, pipeline logs, tickets or chats, and where possible, none at all.