How dangerous is it send HTML in AJAX as opposed to sending JSON and building the HTML?

Question

It seems to me that any interception of this could provide instant trouble because anyone could just send any HTML/script back to the client.

The only reason I'm interested in doing this is because of the huge pain it is for front-end developers every time there's a DOM structure/CSS change so you now have to go figure out where in the Javascript HTML building process you may have to update.

How do you guys deal with this? Are there things I can do to reduce any risk or is ut just straight up bad idea?

Answer 1

I would seem to me that it would be an even bigger hassle to figure out where in the back-end server that would need to be changed when there's a DOM structure or CSS change.

Keeping all of that in one place (the HTML file) is probably the best reason to limit ajax communication to JSON.

Answer 2

With both JSON raw html you still have worry the contents being safe, after all JSON is JavaScript code. I suppose if you don't trust the source of your HTML data then you are open to all sorts of Cross Site Scripting attacks. Consider sending the data as JSON and using Javascript Templating library like the one in Yahoo UI library, see http://developer.yahoo.com/yui/docs/YAHOO.lang.html#method_substitute then let the Front End Guys maintain the templates.

Answer 3

I tend to use the following rules:

1. Request and return HTML for quick snippets, then use client-side (static) Javascript to insert them. Great for alert messages.

2. Request and return JSON for large datasets. This works great when you want to do filtering, grouping, or sorting on the client side without re-requesting the data in a different form.

3. Request and return JSON for large datasets, but include the (escaped) HTML snippet for each record in the JSON record. This means more rendering time and more bandwidth use than (2), but can reduce duplication of often complex HTML rendering.

4. Request and return Javascript, and eval it client-side. This works best for interactions such as hiding, showing, moving, and deleting. It can work for insertions as well, but often type (1) or (5) work better for that.

5. Request and return Javascript, and eval it client-side, but include escaped HTML in the Javascript so the server is doing the HTML rendering.

I probably use 5 and 1 the most often.

Answer 4

I'm not sure I understand the question 100%... but...

We use GWT and send XML between the client and server. I've implemented an XML mapping system using a GWT code generator so the code to translate between XML and JavaScript objects is automatically generated based on the objects themselves (using Annotations in the java classes).

Sending straight HTML just makes your app less capable since it is no longer able to interpret the data in any way, but just updates the screen with it. This also complicates the server side which now needs to generate HTML... I would seriously avoid that strategy.

Answer 5

I have kind of a /task/action/parameter idiom going on the javascript side. My backend strictly returns the data that I need in JSON, the client (js) takes care of displaying it. Say I load this page /#/item/product/5, javascript knows it has to call the "item" object, the method "product" with a parameter 5 passed into it.

This works really well for bookmarking links, so when someone decides to bookmark mysite.com/#/item/product/5 every time that page loads it knows exactly what object..method to call.

Answer 6

I think theres not a big difference in terms of security - you can parse unsafe JSON as well as unsafe HTML/JS.

It's more about proper layering of your app - if you directly inject HTML to your page, youll have to create view-specific code at business logic level, which for my impression is not benefical for clean and easily exchangeable layers.

Just my 2 cents...

Answer 7

The only reason I'm interested in doing this is because of the huge pain it is for front-end developers every time there's a DOM structure/CSS change so you now have to go figure out where in the Javascript HTML building process you may have to update.

You must be doing it wrong.

The data coming back from AJAX should only be semantic data, i.e. stuff that doesn't change if only the layout changes. Converting the data to DOM manipulation is best left to a Javascript function defined in the master page itself.

Answer 8

take a look at: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx

Answer 9

I made this as a comment, but I'm pushing it up.

JSON is inherently safe, the problem is what folks do with it.

Using eval to evaluate it is the problem, not the format, since the format is implicitly limited by the JSON spec. Corrupted JSON can make eval unsafe. So... don't do that. Don't use eval, use a dedicated JSON parser.

Same logic can be applied to HTML. Treat the HTML as "data", as simply XML, and process it, rather than just blindly stamping it in to your pages.

Much harder to shenanigans to slip through that way.