REST Web Services and where to put XSS protection

Question

I am wondering where the best place to put XSS protection in our website. Our team is split up into a front end and back end teams and are using REST as an API between our two groups since we use different platforms. We have a field that could hold a subset of HTML that should be protected and I was wondering at what layer this should be done?

Should it not be allowed into the database by the webservice or should it be validated by the consumer on the way out, ensuring safety? For fields that cannot contain HTML, we are just saving as the raw input, and having the front end escape them before presentation.

My viewpoint is that the webservice should respond that the data is invalid (we have been using 422 to indicate invalid updates) if someone tries to use disallowed tags. I am just wondering what other people think.

Answer 1

It's probably not an either/or. The web service is potentially callable from many UIs, and Uis change over time, it should not assume that all its callers are careful/trusted. Indeed could someone invoke your service directly by hand-crafting a query?

However for the sake of usability we often choose to do friendly validation and error reporting in the UI. I've just finished filling in an online form at a web site that barfs in the service layer if any field contains a non alpha-numeric. It would have been so much nicer if the UI had validated a the point of entry rather than rejecting my request after 3 pages of input.

(Not to mention that if the web site asks you for an employer's name, and the name actually contains an apostrophe you seem a bit stymied!)

Answer 2

You should be using both. The typical pattern is to attempt to sanitize scary data on the way in (and you should really be rejecting the request if sanitization was necessary for a given value) and encoding on the way out.

The reason for the former is that encoding sometimes gets missed. The reason for the latter is that your database cannot be trusted as a source of data (people can access it without hitting your client, or your client might have missed something).