Sanitising Markdown removes or neutralises attacker-controlled formatting before display, while trusting rendered commands allows the UI to execute linked actions from the content. Sanitisation protects the rendering pipeline itself. Trust controls what actions may be triggered afterward. For security-sensitive extensions, sanitising input is the safer baseline, and trusted commands should be tightly restricted.
Markdown sanitisation and command trust solve different problems
Sanitising Markdown is about input handling: the extension removes or neutralises attacker-controlled formatting before it reaches the renderer. That blocks HTML injection, disguised links, and other content tricks from changing what the user sees. Trusting rendered commands is about authorisation of actions: once the UI has rendered content, the question becomes whether a click or command can trigger privileged behaviour.
The practical difference is timing and control surface. Sanitisation protects the rendering pipeline itself, so unsafe markup cannot influence the UI state. Command trust governs post-render interaction, so even a well-rendered message can still be dangerous if it exposes executable links, buttons, or command URIs that run with extension privileges. Those are separate trust decisions, not interchangeable safeguards.
In extension UIs, the safest model is to treat rendered content as untrusted presentation and any action surface as a separate security boundary. If Markdown is allowed to carry links, buttons, or command-like affordances, the extension must validate the target, scope, and destination before execution. The authorization boundary matters because the risk is not just what is displayed, but what the user can be induced to invoke.
Risk and Threat Considerations
The main risk is that content intended for display becomes a command injection path. A malicious Markdown payload can hide a harmful action behind familiar UI formatting, while a permissive command trust model can turn that same content into an execution primitive inside the extension context. Sanitisation reduces the chance of visual deception; command restrictions reduce the chance of privilege misuse.
Failure mechanism: The extension renders attacker-controlled text without fully neutralising active elements, or it accepts rendered commands without sufficiently constraining which commands can fire and under what context. The attacker then uses the UI to move from content influence to action execution.
Impact: Users may trigger unintended navigation, data exposure, state changes, or privileged extension actions. In security-sensitive extensions, that can become a route to broader compromise if the command path can reach secrets, workspace state, or other trusted operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | Covers secure handling of untrusted input and unsafe UI behavior. |
| Recommendation — Sanitise untrusted Markdown before rendering and constrain any interactive UI actions to approved behaviors. | ||
| OWASP Agentic AI Top 10 | A1 — Prompt Injection | Rendered commands can be abused as a content-to-action injection path. |
| Recommendation — Treat clickable or command-like UI content as untrusted and validate every action path before execution. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Supports protecting displayed content and preventing manipulation of trusted UI flows. |
| Recommendation — Protect the rendering pipeline so untrusted content cannot alter security-sensitive UI behavior. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Secrets Exposure and Leakage | Actionable UI content can expose privileged operations that should not be triggered from untrusted text. |
| Recommendation — Restrict executable UI actions so untrusted content cannot reach privileged extension capabilities. | ||
Practitioner Guidance
What to verify: Confirm that sanitisation happens before rendering, not as a post-render filter, and that the renderer cannot reintroduce active behaviour through links, command URIs, or embedded controls. If the UI supports actionable content, verify that each action is explicitly allowlisted and context-checked rather than accepted because it appears in trusted-looking Markdown.
Decision rule: If a control affects only display, sanitise aggressively. If it can trigger code, commands, or privileged extension behaviour, require separate approval logic and keep the action surface as narrow as possible. Do not assume a rendered command is safe because the surrounding text was sanitised.
Practitioner takeaway: The key boundary is between safe display and executable interaction, and the secure design is to treat them as separate trust domains rather than two versions of the same protection.
Related resources from NHI Mgmt Group
- What is the difference between a browser extension risk and a normal SaaS integration risk?
- What is the difference between browser extension trust and identity trust?
- What is the difference between a browser extension risk and a normal SaaS app risk?
- What is the difference between browser extension risk and normal SaaS app risk?
