Is .textContent completely secure?

Question

I'm doing element.textContent = unescapedData to put unescaped user input on a website. Is there any way for an attacker to do something bad using this?

Also, is there any way for an attacker to affect the page outside of element (meaning outside the 30rem by 3rem box) if it has the following css?

max-width: 30rem;
max-height: 3rem;
overflow: hidden;

I've thought about using weird or invalid Unicode characters, but couldn't find any information on how to accomplish this.

Yes, `textContent` is always susceptible to phishing and other social attacks like self-XSS. — Bergi, Mar 23 '17 at 23:06
@Bergi Why is your Answer at comment? Share the knowledge properly and thoroughly — guest271314, Mar 23 '17 at 23:33
@guest271314 Because it's obviously tongue-in-cheek and not an answer — Bergi, Mar 23 '17 at 23:40
It would be better if you ask a new question for your second question(outside the box one). [Check this](https://meta.stackoverflow.com/questions/275908/more-than-one-question-per-post/) — blackmiaool, Apr 09 '17 at 11:49
For the second part of the question, I'm confused as to how you think CSS would effect potential vulnerabilities. Are you expressly worried about XSS? If so, the CSS of the element shouldn't have any bearing. — Nick, Apr 12 '17 at 03:34
@Nick Any way to manipulate the appearance or functionality of the page outside of `element` would count as a vulnerability. — usernumber, Apr 12 '17 at 14:43
Where is the text content coming from? The client's machine? Other clients same domain? or cross domains? — Blindman67, Apr 12 '17 at 15:40

score 13 · Answer 1 · edited May 23 '17 at 12:09

The relevant spec seems to be at https://dom.spec.whatwg.org/#dom-node-textcontent. Assuming element is an Element or DocumentFragment, a Text node is created and its data is set to the string unescapedData. And this Is a DOM Text Node guaranteed to not be interpreted as HTML? seems pretty definitive that a browser won't render a Text node as anything but text. I haven't tracked that down in the spec yet.

So, unless the browser is defective, the answers are "no" and "no".

guest271314 · Answer 2 · 2017-03-23T23:25:09.890

3

Plain text set at .textContent is not executable outside of script element where .type is set to text/javascript.

Would suggest using pattern attribute with appropriate RegEx at input element within form to address potential concerns.

edited Mar 23 '17 at 23:25

answered Mar 23 '17 at 22:18

guest271314

1
15
104
177

Is there a place where this is documented? – Shawn Mehan Mar 23 '17 at 22:20
https://www.w3schools.com/jsref/prop_node_textcontent.asp (If you set the textContent property, any child nodes are removed and replaced by a single Text node containing the specified string.) – malejpavouk Mar 23 '17 at 22:25
@ShawnMehan You can review script element and .textContent at whatwg and w3c specifications to verify – guest271314 Mar 23 '17 at 22:25
1

@malejpavouk Not sure what link is to? Note w3schools is not specification and is not w3c – guest271314 Mar 23 '17 at 22:26
Ok, one more official... https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent – malejpavouk Mar 23 '17 at 22:28
1

@malejpavouk MDN is not official specification either – guest271314 Mar 23 '17 at 22:30
I kinda highly doubt, he is looking for a spec itself...but: https://www.w3.org/TR/dom/#dom-node-textcontent – malejpavouk Mar 23 '17 at 22:38
sorry, forgot that `textContent` isn't used as a function. edited question. – usernumber Mar 23 '17 at 23:02
@usernumber The same should apply. Though have not extensively tried to execute JavaScript at .textContent of an element. What is the expected value of string unescapedData? – guest271314 Mar 23 '17 at 23:05
How exactly do drag'n'drop, `` and `.textContent` relate? – Bergi Mar 23 '17 at 23:09
@Bergi Attempted to convey potential consideration of an element which plain text is expected or not expected as value of filename at filesystem at element; unexpected results could occur. Not sure about exact case of OP. If you consider textarea, .value, drag and drop, contenteditable not relevant to present Question can edit and remove that portion of Answer – guest271314 Mar 23 '17 at 23:15
@Bergi See updated post. Is answer now appropriate? Or should last update also be removed? How can answer be improved? – guest271314 Mar 23 '17 at 23:28

customcommander · Answer 3 · 2020-09-13T20:43:37.200

It depends.

According to rule #6 of DOM based XSS Prevention Cheat Sheet from OWASP:

The most fundamental safe way to populate the DOM with untrusted data is to use the safe assignment property textContent.

So in most cases unescapedData will be interpreted as text (not as code) and rendered as such:

element.textContent = unescapedData

The only exception that I know of is when setting the textContent property of a <script> element. It will be interpreted as code:

const element = document.createElement('script');
const unescapedData = 'alert("xss is possible here")';
element.textContent = unescapedData;
document.body.appendChild(element);

You can see in this article about trusted-types that the textContent property of a <script> element is considered as dangerous sink and will trigger a Content Security Policy violation.

score -1 · Answer 4 · answered Mar 15 '22 at 16:46

If you care about attackers - I suggest you try Dompurify

It's cross-browser. only 19kb gziped

Here is a fiddle I've created that converts HTML to text

const dirty = "Hello <script>in script<\/script> <b>world</b><p> Many other <br/>tags are stripped</p>";
const config = { ALLOWED_TAGS: [''], KEEP_CONTENT: true, USE_PROFILES: { html: true }  };
// Clean HTML string and write into the div
const clean = DOMPurify.sanitize(dirty, config);
document.getElementById('sanitized').innerText = clean;

Input: Hello <script>in script<\/script> <b>world</b><p> Many other <br/>tags are stripped</p>

Output: Hello world Many other tags are stripped

Is .textContent completely secure?

4 Answers4

Linked