Securing software has always been an issue. Whether it be web, desktop or server applications, insecure coding practices can result in substantial data loss for the software users. Although vulnerabilities and exploits differ between technologies, the coding failure is still the same. A lack of input validation allows attackers to break out of the context of the executed portion of code and exploit the result. Although this is a widely understood issue, it still remains a root cause of security bugs. The issue most likely remains because many have failed to utilize the funnel-like nature of data flow.

Front Controller Pattern
The front controller pattern is a pattern that “provides a centralized entry point for handling requests” (Alur). It limits users entry-points to a single interface or service. For example, a web application may provide a single frontcontroller.php page that will then intern interface with other backend components to execute the respond in an appropriate manner.

Application Controller Pattern
The application controller pattern is a pattern used by some of the most well known pieces of software around. It is typically used in web applications but should not be limited to just those platforms. It is used to “centralize retrieval and invocation of request-processing components, such as commands and views”(Core J2EE Patterns). It works by mapping class or function identities to a command that may be provided by a user or client-software. In object-oriented languages, such as Java, the controller will instantiate the appropriate classes, then call the implemented/inherited function. In a scripting language, such as JavaScript, you can map function names and call them respectively (see Figure 1-1).

Use in Security
By leveraging the above patterns we can create an easily reusable, customizable and thorough method for validating user input. The method I will outline involves creating an application controller strictly for security. I will walk you through the logical sequence of using this controller and how each component works:

  1. Client
    The client can gather the parameters in any way the developer prefers. He would then submit that request to the front controller. In a web application use the request may look something like this:

  2. Front Controller
    The front controller limits the amount of input that may be provided by requiring the user to supply only two arguments. These arguments are: Command: the name of the command as it is mapped in the application controller pattern
    Parameters: A set of necessary input, usually in the form of JSON or a standard array of the respective language.This forces all supported commands to conform to this standard, and funnels all user input into a single location that can be scrubbed in sequence or all at once. After receiving the command, the front controller calls the Security Controller for the related request.
  3. Security Application Controller
    This controller contains scrubbing and validation functionality for all specific types of scenarios. This can range from SQL Injection and session validation all the way to character length checks for buffer overflows. The result of each function is a boolean that will dictate whether or not execution continues.The mapping of this controller focuses on creating reusable functions that can be carefully crafted to cover all situations. I have provided some code snippets to highlight what some of the code may look like.

    Mapping Example (Java):

    //the foo command

    Command Interface Example (Java):

    interface SecurityObject {
        bool doStuff(ArrayList parameters);

    Example Command (PHP):

    function validateIsAtLeastManager($parameters){
         $userlevel = $_SESSION['userlevel'];
              if($userlevel <= MANAGER){
                  return true;
              } else {
                  return false;
  4. Normal Application Controller
    This controller contains the normal behavior of the application. It should not receive any extra input, nor should it provide any data except for that which has been processed and used only by the related view
  5. The View
    A response can then be back to the appropriate view and data displayed appropriately. When utilizing client-server architecture (AJAX/PHP) I even utilize the security controller on the client end. This can help prevent things like simple persistent cross-site scripting that may have been injected into the server database. All that is required is content to be sent back to the client in JSON array format with the appropriate command. The client JavaScript controller will then read in the data, scrub it for malicious code, and then write it to DOM according to the commands mapping.

Non-Web Uses
Although these programming patterns are most often implemented in web application technologies, you can do the same thing for desktop and mobile applications. The method is exactly the same. Rather than utilizing an external front controller, I prefer to use a single static class that contains the calling method. I usually implement this through the use of the factory pattern. In addition, I pass a reference of the calling object to provide access to the associated view. Adding a self-reference to the parameters array easily does this.

Existing Frameworks
This controller pattern is available in existing frameworks in multiple different languages. My preferred framework is the QuickConnect framework ( This framework actually utilizes four controllers: validation, business, view, and error. The above explained security controller is implemented in the form of the validation controller, and works in the same way. This framework, as well as others, is easy to implement after a quick overview of the provided samples. I will note that you may be caught off guard by the semi-procedural programming approach that using some of these frameworks involves; but this is hardly something to complain about.

Although the discussed patterns are not new, they are not completely understood by a large portion of developers. With the existence of so many frameworks there is no need to develop your own application controller (although it would not be that difficult). I hope that developers will take the time to implement the above-mentioned principles into their software. Those that do will find it easier to maintain and enhance their code. In addition, a developer can ensure that no portion of code is overlooked when updating security checks for new vulnerabilities.

More importantly I hope this article has served as a means of showing developers how important it is to use good design patterns. Often good practices are neglected because of time constraints and fear of complicating the code. However, the above-described patterns should demonstrate how using such patterns does not complicate, but in fact simplifies the coding process. Add to that the security benefits and there is no reason not to implement these good practices.

Figure 1-2: Security Application Controller

Figure 1-1: The application controller sequence diagram

Alur, Deepak; John Crup, Dan Malks (2003). Core J2EE Patterns, Best Practices and Design Strategies, 2nd Ed.. Sun Microsystems Press. pp. 650pp. ISBN 0-13-142246-4.