Some potential mitigating factors, if you break it up as follows: * a tiny anchor HTML page with data key info * a general purpose .js file (or small number o

Some potential mitigating factors, if you break it up as follows: * a tiny anchor HTML page with data key info * a general purpose .js file (or small number of such) * template HTML pages * content (e.g. - JSON) The tiny "anchor" page should be small (latency still hurts, of course); The JS should be cached locally once the app has been used for the day; The HTML templates pages should also cache; The content must be loaded, suffering latency -- however, if the content is large, your app can display something while the content is being generated (perhaps by a big, slow, legacy data source???). Another consideration: if all content is delivered via a REST API as JSON or (ugh) XML, there is a better chance it will be properly encoded for display. Hopefully, I can save a nice JavaScript fragment in a submission to said site, and the AJAX page construction code will simply add it to the resulting page to be displayed, rather than to be run. Hmmmm, perhaps I want my testing fixtures to fill the test database with XSS samples while I am at it, such as the newer entries in http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html (or a more recent list), and then to display that data on a few pages of manual testing.