Should stored XSS prevention be client or server-side?

Question

What is the best way to prevent stored XSS?

should every text field (even plain text) be sanitized server-side using something like OWASP Java HTML Sanitizer Project?
or should the client protect itself from XSS bugs by applying XSS prevention rules?

The problem with the first solution is that data may be modified (character encoding, partial or total deletion...), which can alter the behavior of the application, especially for display concerns.

I'm voting to close this question as off-topic because it is a cross post of http://stackoverflow.com/q/39084020/413180 — SilverlightFox, Aug 23 '16 at 15:42
Cross posting is a bad habit, but the question is clearly on-topic here, too. — jk - Reinstate Monica, Aug 23 '16 at 15:46
@SilverlightFox IMO, this question is much better suited for this site than Stack Overflow. — Alexander O'Mara, Aug 23 '16 at 15:54
@AlexanderO'Mara: Agreed, however the accepted way for the OP to do that is to flag their question to the moderator and then ask them to migrate it. [See here](http://meta.stackexchange.com/a/10250/241749): `you can flag the question for moderator attention and request that they migrate it for you. ` — SilverlightFox, Aug 23 '16 at 15:58
do both as needed; always sanitize input in a controlled environment (server) and use a CSP on the client. — dandavis, Aug 23 '16 at 17:02

score 1 · Answer 1 · answered Aug 23 '16 at 15:58

Normally for XSS prevention we use html escape character in order the validate the input character or input. According to OWASP here are some of the things that you must follow:

For client side and server side:

Escape character before processing the given input.
Better use security encoding library.
Do not enter untrusted data except in allowed location.
HTML Escape Before Inserting Untrusted Data into HTML Element Content
Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
HTML escape JSON values in an HTML context and read the data with JSON.parse
CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
Sanitize HTML Markup with a Library Designed for the Job
Prevent DOM-based XSS

For server side:

Use HTTPOnly cookie flag
Implement Content Security Policy
Implement and configure WAF like Mod security.
Use the X-XSS-Protection Response Header

There are other prevention measures. You can check this link to get more detailed information.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

score 1 · Answer 2 · answered Aug 23 '16 at 17:16

The most effective solution is probably a mix of input validation and output encoding.

I don't know that you can depend on the client to implement effective XSS mitigations. Hopefully they do, but it's not something you can depend on.

The first question you want to ask is what you do with input that fails validation. Do you remove bad characters and let the rest of input continue? That will make your application unpredictable for the user, which never seems like a good idea.

Another thing to keep in mind is that your data may not always be displayed within HTML. What if your data is included in a PDF document or sent to a printer? Those systems will have their own formats and HTML encoding won't make sense.

Here is the approach I would recommend:

Define the acceptable input in terms of size and character set.
Define your behavior for invalid input.
Validate input and either reject (recommended) or scrub
Use safe methods to store the input in your datastore
When presenting the data back to users encode it properly for the format (HTML, javascript, etc)

There's a risk here that someone on your team may make the assumption because the data is in an internal datastore that it is safe and start using the data without doing proper encoding.

score 0 · Answer 3 · answered Aug 23 '16 at 15:54

0

Ideally; server side. Make sure your code does not place unsanitized user input into the page. But it wouldn't be a disaster to run it client-side. Because the victim is the client where it's checked. This opens up the possibility of the user circumventing the security measure but if done well, that would be quite a hassle.

answered Aug 23 '16 at 15:54

J.A.K.

4,793
13
30

Could you expand your answer to explain what client side protection is viable, and what isn't? It would also be good if you explain "the victim is the client", which is the whole point of XSS. – Alexander O'Mara Aug 23 '16 at 16:00
XSS needs three nodes, hence the cross. Here i was talking about stored and reflected XSSs, in both cases the server is also the victim of being an involuntary trusted source of malicious code. Both sides can stop the attack. Reflected attack scenarios have the attacker supply the victim with a malicious URL. The client then has the server reflect the malicious content into the page. With stored XSS, the malicious code is stored in the servers database and presented as a comment or username for example. Serverside is ideal because it is aware of untrusted input. See answers above for the rest. – J.A.K. Aug 23 '16 at 16:31

score 0 · Answer 4 · edited Mar 17 '17 at 13:14

The client should not be responsible for preventing any type of XSS apart from DOM based XSS, although security headers can help it to not execute anything it is not meant to. XSS prevention is still the responsibility for the server, apart from DOM based XSS.

The browser client is also useless at validation because an attacker will bypass it to achieve XSS.

I've updated this question here though for how to prevent all types of XSS. https://security.stackexchange.com/a/134722/8340 (also more information on security headers).

Should stored XSS prevention be client or server-side?

4 Answers4