Difference between innerText and innerHTML

When binding data to the document, there are various attributes used to bind element contents:

• data-bind:text
• data-bind:innertext
• data-bind:inner-text
• data-bind:textcontent
• data-bind:text-content
• data-bind:html
• data-bind:innerhtml
• data-bind:inner-html

What's the difference?

The first thing to know is that text, innertext, inner-text, textcontent, and text-content are all synonyms - and so are html, innerhtml, inner-html, htmlcontent, and html-content.

The text bind properties are mapped to the DOM property Element::textContent and the html bind properties are mapped to the DOM property Element::innerHTML.

Certain values will look identical if you use text or html, but there is one very important difference which is how the developer expects the content to be used. If the text content is expected to be exactly that, text content, data-bind:text should probably be used. If there is expected to be HTML characters within the bound data, then data-bind:html might be the correct choice.

It's important to understand the risks of using data-bind:html first though.

Cross site scripting (XSS)

Any website that deals with dynamic data has to be wary of XSS, an important security vulnerability that could be caused by malicious or accidental use.

When using data-bind:html, the exact value of the string that is bound to the document will be directly injected into the document, byte for byte. This might be what you expect, if you're setting something that should contain HTML content, but if you are dealing with text only, it could be very bad to inject exactly what the variable contains into the page, especially if the content has been supplied by the user.

Example

Imagine a user sets their own display name, and a list of users is shown on the homepage.

Given this HTML:

<h1>User list</h1>
<ul>
	<li data-list data-bind:html="displayName">User name</li>
</ul>

We can assume the list of users is being loaded from a database, but in our contrived example we will hard-code the data in PHP:

function example(DocumentBinder $binder):void {
	$userList = [
		["displayName" => "Greg"],
		["displayName" => "Sarah"],
		["displayName" => "Cody"],
	];

	$binder->bindList($userList);
}

The output of the above would look like this:

<h1>User list</h1>
<ul>
	<li>Greg</li>
	<li>Sarah</li>
	<li>Cody</li>
</ul>

There's nothing seemingly wrong with that output, but the problem comes if the user sets their name to something that you didn't expect:

function example(DocumentBinder $binder):void {
	$userList = [
		["displayName" => "Greg"],
		["displayName" => "Sarah"],
		["displayName" => "Cody<script>alert('you got pwned')</script>"],
	];

	$binder->bindList($userList);
}

Look at the third user's display name now: it contains a <script> tag. This is bad news when using data-bind:html because it will be injected directly into the HTML of the page, and the script's contents will be executed.

Using data-bind:text will encode the HTML in a way that it will still visually display, but won't execute in the browser.

When dealing with any user-provided data, it's always a good idea to sanitise it upon entry using tools such as strip_tags, depending on your expected use of the data.

OWASP

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws, see: Types of Cross-Site Scripting.

OWASP is a nonprofit organisation which aims to improve software security knowledge. If you haven't already, please read their documentation on XSS, along with the other top 10 security vulnerabilities.

https://owasp.org/www-community/attacks/xss/