Unparsed Raw Web Content Delivery happens when web content is served to a browser without being properly parsed, encoded or sanitised first. An attacker can smuggle script or markup through and cause cross-site scripting or content injection. Defenders should set the correct content type, encode untrusted output, and sanitise any user-supplied HTML or script-like content.
How raw web content becomes unparsed instead of safely rendered
The failure starts before the browser ever sees the page. Content is passed through as if it were safe text, but the server or template layer does not apply the parsing and output rules needed to distinguish content from code. That usually means the application emits user-controlled HTML, script-like text, or markup in the wrong context.
When that boundary fails, the browser interprets the payload as active content rather than inert text. The result is often cross-site scripting, but content injection can also show up as broken layout, unexpected navigation, or altered page behaviour when markup is accepted where plain text was intended.
One useful way to think about the problem is that the application has skipped the trust boundary between stored data and rendered output. The content may be valid from a business perspective, but it is unsafe for a browser unless it is encoded for the exact output context.
Which input handling mistakes usually cause it?
The most common causes are missing output encoding, incorrect content-type handling, and weak sanitisation of user-supplied HTML. If untrusted data is written into a page without escaping characters such as angle brackets, quotes, or event-handler syntax, the browser may reconstruct active markup from what was meant to be plain text.
A second cause is context mismatch. Data that is safe in one place, such as plain text in a text node, can become dangerous when reused inside an attribute, script block, style block, or rich text field. The protection must match the rendering context, not just the source of the data.
For web teams, the practical issue is that sanitisation is not interchangeable with encoding. Sanitisation removes or rewrites dangerous HTML fragments, while encoding makes text inert for the browser. If the application is expected to render rich user content, the allowed tags, attributes, and protocols need to be tightly controlled.
On the source side, unsafe helpers and templating shortcuts are common contributors. If a framework offers auto-escaping, bypassing it for convenience can reintroduce the flaw. If a page consumes markdown, WYSIWYG HTML, or imported legacy content, the transformation pipeline needs the same scrutiny as direct form input.
What defenders should verify in delivery paths and rendering controls
Check the full path from storage to browser, not only the original input form. A page can be vulnerable even when input validation exists, if later processing removes protections, concatenates fragments unsafely, or changes the output context after validation has already happened.
The response should declare the correct content type, encode untrusted output for the target context, and sanitise only when rich HTML is truly required. If a page is meant to display text, it should never rely on the browser to "do the right thing" with untrusted markup.
For broader web attack context, NHIMG’s Web Application Attacks Guide covers how injection classes commonly overlap in real exploitation chains. When the issue is content delivery and filtering rather than application logic, NHIMG’s Secure Web Gateway and Web Filtering Guide is the better fit for understanding how inspection and bypass controls affect what reaches users.
Defenders should also verify that security headers and browser handling do not contradict the application’s intent. A page that declares HTML but serves unsafe user content is still vulnerable, even if the underlying transport is encrypted. The important control is whether the browser ever receives attacker-controlled markup as executable content.
Risk and Threat Considerations
Unparsed raw content delivery creates a direct injection path from untrusted input to browser execution. That makes the issue attractive to attackers because it can turn ordinary content fields, comments, profiles, or imported documents into script execution points without needing deeper application access.
Failure mechanism: The application fails to encode or sanitise output for the browser context, so attacker-controlled markup survives rendering and executes as active content.
Impact: This can enable cross-site scripting, session theft, account actions in the victim’s browser, and content tampering that undermines user trust and page integrity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Raw web content delivery fails when output is not encoded or sanitized for the browser context. |
| V16 — Security Logging and Error Handling | Unexpected parsing or injection errors should be visible in logs without exposing raw payloads to users. | |
| Recommendation — Require context-aware output encoding and sanitization for every untrusted rendering sink. Log parsing and sanitization failures so unsafe rendering paths are detected quickly. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure application design and validation practices address unsafe web content handling before release. |
| Recommendation — Build secure output handling and review render paths during application security testing. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Injected script-like content becomes dangerous when the browser interprets attacker input as executable code. |
| Recommendation — Trace executable payload delivery paths and hunt for script execution opportunities in web content flows. | ||
Practitioner Guidance
What to verify: Confirm that every output sink is context-aware, not just every input source. The critical question is whether text, attribute, script, style, and rich HTML contexts are handled differently, because a single generic escape step is not enough for all of them.
Common mistake: Teams often assume that "sanitised somewhere upstream" is sufficient. In practice, later concatenation, template reuse, or markdown rendering can reintroduce raw content after the original check has already passed.
Practitioner takeaway: Treat browser rendering as a separate security boundary, and only allow untrusted content to cross it after it has been encoded or sanitised for the exact context in which it will appear.
Related resources from NHI Mgmt Group
- Guide: CWE Top 25 Guide
- Unparsed Raw Web Content Delivery
- Why do MCP servers that return raw web content increase the risk of sensitive data exfiltration?
- Why do AI agents make content delivery a governance issue?
- How should security teams govern Chrome extensions that can read sensitive web content?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org