bcquality/microsoft/knowledge/security/use-nondebuggable-when-parsing-secrets.md

bc-version	domain	keywords	technologies	countries	application-area
all	security	nondebuggable secrettext attribute parse	al	w1	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.