bcquality/microsoft/knowledge/security/use-nondebuggable-when-parsing-secrets.md
Jesper Schulz-Wedde 5bcdc55df9 Sync knowledge articles with review agent instructions
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-05-05 14:08:32 +02:00

29 lines
1.6 KiB
Markdown

---
bc-version: [all]
domain: security
keywords: [nondebuggable, secrettext, attribute, parse]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Use NonDebuggable when parsing secrets
> Contributions welcome — open a PR to refine or extend this article.
## Description
SecretText transit (assignment between SecretText variables, parameters, and return values) is protected automatically. Extracting a secret from a Text source — for example, reading an access token out of a parsed JSON response — is a legitimate Text-to-SecretText conversion during which the plaintext exists. Calling `SecretText.Unwrap()` has the same exposure in the opposite direction: it materializes the secret as plain Text. The [NonDebuggable] attribute prevents debuggers (regular and snapshot) from inspecting the procedure's locals, parameters, and return at that moment.
## Best Practice
Apply [NonDebuggable] to any procedure that reads a response body, parses it, and assigns the extracted secret to a SecretText out-parameter or return. Also apply it to every procedure that calls `Unwrap()` because the secret becomes plain Text inside that procedure. Keep the procedure narrow: it SHOULD do the minimum work required to obtain or unwrap the secret, and nothing else.
See sample: `use-nondebuggable-when-parsing-secrets.good.al`.
## Anti Pattern
Parsing a token response in a normal (debuggable) procedure, or calling `ApiKey.Unwrap()` there to build a legacy Text value. The plaintext token is visible in debug sessions and snapshots taken during the parse or unwrap.
See sample: `use-nondebuggable-when-parsing-secrets.bad.al`.