The clearest warning signs are inconsistent escaping, unexpected HTML elements surviving conversion, and preview output that reflects attacker-controlled structure instead of inert text. If a document preview can introduce scripts, event handlers, or dynamically generated tags from untrusted content, sanitisation has failed. Teams should test the full conversion path, not just the final browser rendering step.
How to tell sanitisation is failing, not just rendering quirks
Attachment preview sanitisation is failing when the preview output preserves attacker-controlled structure instead of reducing it to inert content. That usually shows up as markup surviving conversion, escaping that changes unpredictably, or visible elements that should have been neutralised. The key question is whether the preview path is still capable of introducing active behaviour into the browser.
A healthy preview pipeline should strip or encode executable constructs before the browser sees them. If the preview output changes depending on file type, content length, or nested formatting in ways that expose raw tags, attributes, or partially interpreted fragments, the converter is not reliably collapsing untrusted content into safe text.
The strongest sign is when the preview contains structure that should not exist in plain rendering, such as unexpected HTML elements, broken tag boundaries, or content that looks “almost escaped” but still behaves like markup. That means the sanitiser is either incomplete, applied too late, or operating on the wrong representation of the document.
What failure looks like in practice
Failures often reveal themselves through inconsistent treatment across the conversion chain. For example, one path may escape angle brackets correctly while another leaves event-handler-like attributes, auto-linked content, or embedded objects intact. The preview may look harmless until a browser interprets fragments as active DOM rather than static text.
Another practical indicator is when the previewed attachment reproduces attacker-controlled layout or hierarchy, rather than flattening it. If a document preview can carry over scripts, dynamic tags, or other active elements from untrusted input, the sanitisation boundary has already been crossed. The problem is not limited to obvious script execution; preserving any executable structure in a preview is evidence of control failure.
Teams should also watch for path-specific inconsistency. A file may appear safe in a backend sanitiser report yet still render unsafely after conversion to HTML, PDF-to-HTML transformation, or browser-side preview assembly. That gap often means the control is being validated at the wrong stage. NIST SP 800-88 Media Sanitization is about data disposal rather than webmail rendering, but it usefully reinforces the same control principle: sanitisation has to be effective at the point where untrusted content changes form.
What practitioners should test before trusting the preview
Test the full conversion path end to end, not just the final browser output. That means validating the source document, any intermediate transformer, the sanitiser, and the rendered preview as separate checkpoints. If one stage passes only because later stages happen to mask unsafe output, the control is brittle and may fail under a slightly different file type or rendering engine.
What to verify: confirm that the preview output contains only inert text for attacker-controlled input, with no surviving executable tags, event handlers, embedded objects, or browser-interpretable fragments. Also verify that malformed input is rejected or normalised consistently, not partially rendered.
What good looks like: the same malicious attachment produces harmless, visibly escaped text across all preview modes, and there is no difference between “safe-looking” and actually safe output. When in doubt, inspect the DOM or generated markup, not only the visual screenshot, because a preview can look benign while still carrying hidden active structure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Preview sanitisation is an input-to-output trust boundary that must block malformed or hostile content. |
| SI-3 — Malicious Code Protection | Unsafe attachment previews can deliver active content that this control is meant to detect or block. | |
| Recommendation — Validate attachment content before rendering and reject or normalise unsafe structures. Scan and block attachment content that can become executable in the preview path. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | The issue is whether untrusted content is correctly encoded and sanitised before browser rendering. |
| V15 — Secure Coding and Architecture | The answer depends on building a safe rendering pipeline with explicit trust boundaries. | |
| Recommendation — Apply encoding and sanitization at every transformation step before preview output is generated. Design the preview pipeline so untrusted content cannot reach the DOM as active structure. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Webmail preview sanitisation is an application security control problem in the rendering stack. |
| Recommendation — Test application rendering paths for unsafe content handling and fix conversion weaknesses. | ||
Practitioner Guidance
What to prioritise: treat preview sanitisation as a content-transformation control, not a cosmetic rendering issue. The first priority is proving that untrusted attachment content is reduced to inert output before any browser can interpret it.
Common mistake: teams often test only with obvious script payloads and miss partial failures such as surviving attributes, nested tags, or inconsistent escaping in alternate document types. Those weaker failures matter because they show the sanitiser is pattern-based rather than structurally safe.
Decision rule: if the preview system can preserve attacker-controlled HTML structure in any supported format, assume the sanitisation boundary is broken and validate the entire pipeline before relying on the feature. If the only thing preventing execution is the current browser or current file format, the control is not dependable.
Practitioner takeaway: A trustworthy webmail preview does not merely hide scripts, it converts untrusted attachments into output that cannot be reinterpreted as active structure anywhere in the rendering chain.
Related resources from NHI Mgmt Group
- What are the signs that PDF sanitisation is failing to remove dangerous active content?
- What are the signs that a multi-agent system is failing to stay within its intended boundaries?
- What are the signs that a RAG system is failing its access controls?
- What are the signs that a system prompt is failing under attack?
