public interface XssAndCSRFSecurity
     <script>alert("Hacked!")</script>
  
  then inserting that field value into an HTML document will cause the script to execute.
  
 The way to prevent this kind of attack is DataSourceField.escapeHTML.  Setting
  that flag on your fields will ensure that script embedded in field values won't
  execute; because it is escaped, the value will be treated as literal text.
 
  
A CSRF token is a unique string of text that you generate on the server on session creation, and then expect to be passed as a parameter with all future requests. By storing the CSRF token in the session and comparing it to the passed token parameter, you can be sure that the request came from a source that is privy to the CSRF token, and thus that the request is not forged.
  implementing a CSRF token strategy is really easy with Smart GWT, especially if you 
  are using the Smart GWT server framework.  Since all data-related requests go to a 
 single URL, specified with actionURL, you
 can just add your CSRF 
  token to that URL in your bootstrap file.  Alternatively, you could use 
 RPCManager.transformRequest() to
 add your token, if your authentication system 
  requires the CSRF token in another part of the request (for example, in an HTTP header).
  Using a CSRF token is a highly recommended security practice.
 
  
  The "hiddenFrame" protocol uses an iframe to load content from the server.  If your
  page sets document.domain at all, an iframe must have a matching 
  document.domain setting or it can't contact the main page to report 
  results.  Due to proxying and other commonly-used techniques, there is no reliable way
  for the server to know what document.domain setting must be used.
  Therefore, Smart GWT passes the setting to the server with each "hiddenFrame"
  request, in a parameter called isc_dd, and the server echoes that setting
  back down to the client.
  
  Domain synchronization opens up the potential for an obscure hybrid XSS/CSRF attack on
  a Smart GWT application, where it shares a domain with another, non-Smart GWT 
  application that is vulnerable to XSS attacks - for example, a Smart GWT app at 
  payments.example.com and a non-Smart GWT app at 
  enquiry.example.com.  This attack would work by injecting an XSS payload 
  into the vulnerable, non-Smart GWT app at enquiry.example.com; this 
  injected code would set the domain to "example.com", and then create an iframe that
  targets the Smart GWT app at "payments.example.com", passing isc_dd as
  "example.com".  The return function from that CSRF call would be able to access data 
  from "payments.example.com", as a result of exploiting an XSS  vulnerability in the app
  at "enquiry.example.com".
  
document.domain, there is no need for 
      domain synchronization, and you can simply switch it off by specifying
      domainSync.disabled: true in your server.properties filedocument.domain, you can prevent this 
      kind of exploit by providing a comma-separated list of valid base domains in 
      server.properties setting domainSync.baseDomains.  For 
      example, the following setting would have prevented the above attack:
      domainSync.baseDomains: payments.example.combaseDomains setting as described above, the system will log a 
  warning every time it echoes a client-provided domain name in a response.