Inexpressible, not sanitised

Last reviewed: September 2026. Figures cite the edition of each source current at that date; we update when the sources do.

Cross-site scripting was first described in a CERT advisory in February 2000. A quarter of a century of escaping libraries, templating engines and content policies later, MITRE's 2025 ranking of the most dangerous software weaknesses puts it first, for the second consecutive year, scored over 39,080 CVE records; SQL injection is second and cross-site request forgery third. On HackerOne it has been the most reported class in every published edition of the platform's report, at between 18% and 26% of all submissions. A weakness that well understood does not survive that long through carelessness. It survives because of where it lives.

Every web framework in common use hands an author a string and a sink, and asks that the two be kept apart by discipline: escape the text here, allow-list the URL there, remember that an attribute name has no escape at all. The discipline is sound. What the ranking measures is the failure rate of a sound discipline applied by millions of authors, in millions of places, every day.

Generative UI multiplies the sinks

A model that writes React or HTML is one more author producing strings, with two differences. It produces them at a rate no code review keeps up with, and it reads content an attacker may have written. OWASP's Top 10 for LLM applications lists prompt injection first and improper output handling fifth, and the two chain: instructions planted in a document the model reads become a payload the model emits, which the application executes because it trusted its own model. Every such chain terminates at a sink, and the conventional answer is to sanitise harder at the point of arrival.

Fuaran's answer is that the sink should not exist at the language boundary. A model emits a tree of typed nodes, and the vocabulary of that tree has no slot for a script, no raw-markup node, no free-form style value and no attribute bag. A handler serialises to a fixed sentinel and decodes to nothing callable. A URL is data that every rendering host must pass through the same scheme floor before it reaches an href; presentation is a token that maps to a class the renderer owns, never a CSS string an author supplied. The payload that would have needed sanitising cannot be written down. What the model can express, the decoder checks against a closed vocabulary before anything renders, and an intent to reach the host (to navigate, to write state, to call a registered tool) stays inert until a policy the host controls admits it. And an agent that reads the interface it operates is told which text came from data rather than from an author, marked untrusted, so the model is not the only party that knows the difference.

That is a claim about a language, and a language is only as safe as its hosts, so the evidence is per host. The hostile-input family of the shared conformance corpus states the floor as semantic invariants (this payload must be refused, this one must be rendered inert, this one must survive because it is harmless) and runs in the suite of each of the five codec hosts. Building it found the same attribute-name defect open in three hosts that the reference host had already closed, which is the corpus doing its job rather than a reader doing it. The reference decoder's fuzz record is regenerated by the run that produces it: 500,000 generated inputs, none of which escaped as an exception, hung, or breached its allocation budget; the other four codec hosts run a bounded leg of the same families on every pull request. The per-seam sanitisation contract names where each check lives in the source.

The proportion, honestly

None of this touches the attacks that cause most breaches. Verizon's 2025 breach report finds stolen credentials the most common initial vector, in 22% of breaches, and involved in 88% of basic web-application attacks. The OWASP Top 10 for 2025 ranks injection fifth, behind broken access control, misconfiguration, supply-chain failure and cryptographic failure. A closed UI language has nothing to say about a phished password, a mis-scoped role, or a poisoned dependency; those belong to the host application, and the security page says so at length.

So the honest statement is that Fuaran removes the weakness class most prevalent in code, not the attack most prevalent in breaches. Those are different quantities, and conflating them is how a UI library ends up claiming to secure a site. What makes the narrower property worth having is that it is removed once, at the language, for every conforming host, rather than re-earned by every author at every sink; and that it is precisely the class generative UI would otherwise multiply, since a model emitting markup is an author whose output nobody reads before it runs. A claim that can be scoped that exactly, and checked against a published corpus, is worth more to a security reviewer than a broader one that cannot.