Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm going to be developing a single page JavaScript app which allows input via a textarea. This input is never sent to the server, never shown to another user, and will only be persisted in browser memory as long as they are on the page. Any input will need to be redisplayed to the user who has entered it.

  1. What attack vectors are there in this kind of scenario?
  2. What would you do to mitigate any attack vectors?

Options to me seem to be dumb JavaScript HTML encoding before adding to the DOM or simply keeping the textual input in the textarea as is and disabling it.

share|improve this question
Does the variable get stored in a GET parameter? – Lucas Kauffman Oct 30 '12 at 12:50
It does not. Any persistence of data will be through DOM storage and JavaScript arrays/objects. – Maleks Oct 30 '12 at 13:57
up vote 2 down vote accepted
  • What attack vectors are there in this kind of scenario?

DOM-based XSS is the big one.

Normally that can allow a host of things key-logging, exfiltration of data on the page, XSRF, redirection to a phishing site, drive-by-downloads.

But as long as it is only redisplayed to the user who entered it and does not persist, it's not really an issue.

  • What would you do to mitigate any attack vectors?

Use document.createTextNode(plainText) to insert text into the DOM instead of node.innerHTML = plainText.

Make sure that you do not pre-populate the text box with data from the URL so that it really is true that the data is entered by the user.

Do not allow framing of your site to prevent an attacker's page from wrapping your page and socially-engineering the user into copying&pasting content into the textbox.

share|improve this answer
Exact answers to my questions. Many thanks Mike. – Maleks Dec 4 '12 at 9:53

The two biggest threats are Clickjacking and accessing the offline storage. The offline storage maybe accessed with DOM Based XSS or if the machine running it has been compromised. Even if your application doesn't use GET/POST/Fragment as input, one of your libraries might.

share|improve this answer
Thanks for that. Is there anything in particular you would do to mitigate against these vectors? – Maleks Oct 30 '12 at 17:24
@Maleks I would read the links provided. – rook Oct 30 '12 at 17:46

Avoid client-side XSS (also known as DOM-based XSS). Read OWASP for resources on this topic. See also Adam Barth's advice on this subject, which is excellent.

A short version: for heaven's sakes, don't use setInnerHTML, document.write(), or eval() on the text the user enters into the textarea. Use setInnerText (or document.createTextNode etc.) instead of setInnerHTML.

share|improve this answer

Assuming no data is read from anywhere (such as GET parameters), the only possible attack is that the html document is tampered with when it's loaded. If it's loaded locally, the version on the disk may be tampered with; if it's loaded from a server without https, the document may be changed during the transfer or changed on the server.

Other than that, if there is no input or output (besides what is typed and visible on the screen; I mean things like saving to disk), I don't see what attacks you could execute that you can't on every other input field on the system.

Edit: Oh, missed this part: Any input will need to be redisplayed to the user who has entered it. The sentence before that one suggested it would be deleted. That might indeed be an attack vector, for example when that cache is tampered with. I don't think there are big risks in this though.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.