Web Security Guidelines

Web applications present developers with more security challenges than a desktop or client/server application. Application and network security can no longer be treated as separate realms, and web applications are responsible for maintaining user state and addressing the many security threats that arise out of the open nature of the web.

These security guidelines are intended to alert you to the types of threats that web applications need to defend against, and the ways in which you can design and implement your Rocket® Uniface web application to do this.

Web applications have the following architectural characteristics that affect their vulnerability to attack and the defenses that can be put in place to prevent attack:

  • Web applications are stateless—the application is therefore responsible for tracking state for each user. To manage state, web applications require additional data to be passed between the remote client and the web server. Unfortunately, this data can be visible to the user or a third party via the network and through the browser, making it vulnerable to tampering and misuse.
  • Web applications have no control over the client environment—the web browser is typically located on a remote site, and the application has no control over the environment that the browser runs in, or the network that it uses to communicate with the application. Hackers can install programs in these environments to intercept the data exchanged between the client and the server.
  • The network is part of the web application—traditionally, security has been divided into the distinct realms of application security and network security. However, in web applications, the network becomes part of the application, so security issues on both levels can no longer be dealt with separately. Applications have to be aware of the openness of the network they are on.

Trust in Data

Application security is a matter of trust—what input can be trusted? what input cannot be trusted?

The level of trust determines what the application does with the information. Conversely, the way the information is to be used in a particular application area determines the minimum level of trust in that information.

Tip: As a general rule, input from the browser should never be trusted, because the application has no control over the network or the user's environment.

This means that your application should be designed in such a way that for each interaction between the browser and the server:

  • The user's identity must be reliably verified (authentication)
  • The user's privilege level must be reliably verified (authorization)
  • All input data must be validated as if the user directly entered it into an input form.
    • This should be done even for hidden fields, cookies, and query string parameters that are used for state management
    • The application should not rely on validation done by the browser
  • All output data is treated as if it is directly visible to the user or a third party through the network or the browser