With regard to AJAX, you have to keep in mind the following security risks:

1. Code Injection
   The main risk is the so-called "code injection".

   To prevent code injection, all data needs to be checked on the server side. For this purpose, Application Designer offers the IRequestDataConverter interface. This filter enables you to convert values coming from the user interface client: each data request contains values of changed properties. Each property value that is transferred into the Application Designer server may be passed through an instance of this interface.

   Background: in certain scenarios you may want to make sure that certain values are not passed into your application system. For example, for reasons of security, you do not want to enable inline scripting or inline SQL statements; therefore, you want to make sure that a user cannot input JavaScript statements or SQL statements. The cisconfig.xml file contains the parameter requestdataconverter. In order to make use of your data converter, specify the name of your data converter with this parameter. Example:

   <cisconfig .. requestdataconverter="com.your.RequestDataConverter" />

2. Faked Client
   The second risk is a so-called "faked client" which sends bad HTTP sequences, hoping that there is no server-side validation.

   In this case, the responsibility is on the developer's side. Application Designer offers a client-side validation: the regular expression /d/d/d/d as the validation for a field; the field expects 4 decimal digits which will be validated on the client side. A faked client does not provide any validation. Thus, it depends on the developer to implement a server-side validation as well. One approach is to assume that all data that arrives from the client side might be wrong, even the data that is returned from a combo box. Therefore, if data might be wrong, it is important to double-check it on the server side.

3. Customizing Error Pages
   In the case of unexpected errors, most application servers show a default error page. This default error page mostly contains information such as stack traces. Showing full stack traces in a production environment is regarded as a security risk. To avoid this vulnerability, you can configure your own error pages in the web.xml file of your web application. For your convenience, the product contains a ready-to-use error handling servlet. The following example shows how to configure this servlet in the web.xml file:

   <servlet id="DefaultErrorHandler">
            <servlet-name>DefaultErrorHandler</servlet-name>
            <servlet-class>com.softwareag.cis.server.DefaultErrorServlet</servlet-class>
   </servlet>
    
   <servlet-mapping>
        <servlet-name>DefaultErrorHandler</servlet-name>
        <url-pattern>/DefaultErrorHandler</url-pattern>
   </servlet-mapping>
    
   <error-page>
         <exception-type>java.lang.Throwable</exception-type >
         <location>/DefaultErrorHandler</location>
   </error-page>

   The following is a sample error page that has been generated by the com.softwareag.cis.server.DefaultErrorServlet:

   

   As an alternative to this default error handling servlet, you can add your own error handling servlets and/or error pages.