Dangling markup injection is a web attack that uses incomplete HTML or attribute markup to make a browser leak data into attacker-controlled content. It can expose tokens, page fragments or reflected secrets when a page concatenates untrusted input into markup. Defenders should encode output correctly and avoid placing secrets near injectable markup.
How dangling markup injection works
Dangling markup injection is a browser parsing trick, not a full code execution bug. It works when attacker-controlled input is inserted into HTML or an attribute without safe encoding, allowing the browser to keep reading markup in a way that can capture and disclose nearby page content.
The danger comes from how HTML parsing tolerates incomplete tags and attributes. If a page builds markup by concatenation, the attacker can cause the browser to treat later text as part of the injected structure, which may reveal tokens, reflected secrets, or other sensitive fragments that were never meant to leave the page.
Where the leak comes from
This attack usually depends on a page that places untrusted input into a context where the browser can reinterpret it as markup. The injection point may be a text node, an attribute value, or a partially closed tag. Once parsing is disrupted, the attacker can shape the surrounding DOM in a way that exposes data the application assumed was inert.
The issue is especially dangerous when applications render secrets near user input, such as CSRF tokens, session-related values, hidden metadata, or reflected personalization data. The browser does not need to “execute” the secret for harm to occur; the problem is that the secret can be folded into attacker-controlled content and then exfiltrated through the page structure itself.
Why output encoding is the real control
Correct output encoding is the primary defense because it preserves data as data rather than markup. The response should be encoded for the exact context in which it appears, and untrusted content should never be dropped into HTML construction logic as raw strings.
Defenders should also keep sensitive values away from any region of the page that could be influenced by user input. If the application must render untrusted content, use safe templating or context-aware escaping instead of manual string concatenation, and avoid mixing secrets with markup that can be reinterpreted by the browser.
How to think about exposure and verification
Exposure checks start with code review and template review, then move to runtime testing of the exact rendering path. Focus on pages that reflect input into HTML, attributes, or script-adjacent markup, and verify whether the browser can break out of the intended context when input is truncated, unclosed, or malformed.
The practical question is not whether the page “looks safe” in a browser, but whether any untrusted field can alter the structure of the response. If yes, the page should be treated as vulnerable until the output context is fixed and the affected rendering paths are retested.
Risk and Threat Considerations
Dangling markup injection can turn a minor reflection bug into a data exposure issue because the browser may leak values that were never intended to be user visible. The most serious cases involve pages that place secrets, session-adjacent values, or personalization data close to attacker-controlled markup.
Failure mechanism: The attacker injects incomplete HTML or attribute syntax, the browser continues parsing beyond the intended boundary, and sensitive adjacent content becomes part of attacker-controlled output or an extractable fragment.
Impact: Tokens, page fragments, or reflected secrets may be exposed, which can lead to session compromise, account abuse, or secondary attacks that rely on stolen page content.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Dangling markup injection is prevented by context-aware output encoding and sanitization. |
| V15 — Secure Coding and Architecture | This attack arises from unsafe string-based markup construction and unsafe template design. | |
| Recommendation — Encode untrusted data for its exact output context before rendering it into HTML. Remove raw string concatenation from response generation and use safe templating patterns. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The term is a web application attack pattern that belongs in secure application testing and remediation. |
| Recommendation — Test web rendering paths for injection flaws and fix the affected templates or handlers. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted input reaching markup without proper handling is the core failure condition behind the attack. |
| Recommendation — Validate and handle input so it cannot alter the structure of generated web content. | ||
Practitioner Guidance
What to watch for: Prioritise any rendering path that uses string concatenation, partial templates, or dynamic attributes. Those are the places where context confusion is most likely to create a dangling-markup condition.
Governance implication: Treat output encoding as a design requirement, not a last-stage filter. Review page templates for secret placement as well as encoding, because safe encoding alone does not compensate for putting sensitive material in a risky location.
Related resources from NHI Mgmt Group
- Guide: Web Application Attacks Guide
- What is the difference between untrusted user markup and server-side template injection?
- What is credential injection risk and how does it occur?
- What is the difference between prompt injection risk and identity abuse in agents?
- What is the difference between prompt injection and credential theft for agents