The subject security is not to be imagined as not existing in a time of the free availability of data, countless bot networks and SPAM dispatch from web applications any more. On this occasion, not only the juridical background plays a big role, but also the security and stability of the hosting systems is dependent directly from the security and the stability of the applications. That's why it is essential that the used tools or frameworks already are security and stable by design.

The following list indicates features of the APF which already provide out-of-the-box security:

  • Input and output filters
    As of the 1.5 release, the framework possesses generic input and output filters, that are executed on page or front controller startup to safeguard user input (GET and POST). This generates a kind of "basic security" and increases the security of an application compared to other tools explicitly .
    Since the 1.9 branch, the input and output filters can be influenced by the developer. Hence, you can now write special input filters for special cases to safeguard your application so much better.

  • Form filters
    As of the 1.9 branch, filters can also be applied to text fields within APF forms. This enables you to secure your application on dedicated places (e.g. login form) and avoid SQL injection by filtering problematical characters or escape sequences.

  • Configuration:
    Configuration duties are strictly done by the ConfigurationManager. This component uses no parameters from the REQUEST and is used only by the application itself. Thus, XSS attacks are not taking place by design!

  • URL layout:
    The URL layout must correspond to a defined schema. Hence, possible XSS gaps strike by use of the LinkGenerator components by the fact that a URL cannot be parsed and the called components indicate an error.

  • Templates:
    The page controller processes templates not as PHP scripts like many other frameworks do. The PHP code which may be smuggled into the code by XSS holes - if the software built on the framework has such security holes - hence, is not executed, but is brought to display as is.

  • Bootstrap architecture:
    Because of the bootstrap architecture (=every request is handled by a single php file) requests like /content.php?seite= cannot affect the operation of the application.

  • URL parameters:
    Parameters in urls that directly influence templates including functionality do not reach the file system directly and uncontrollably, due to the fact, that they are validated and are only legal in a dedicated namespace. If a template is not found, an application error is thrown, so that the readout of system files is not possible. URL parameters in front controller actions are abstracted, by a configuration and do not access file system resources directly.

Further reading on XSS and security can be obtained in the Hacking & the APF 2009/2010 article or in the forum (German). The website also contains very interesting stuff on PHP security.


Do you want to add a comment to the article above, or do you want to post additional hints? So please click here. Comments already posted can be found below.
There are no comments belonging to this article.

In order to provide a state-of-the-art web experience and to continuously improve our services we are using cookies. By using this web page you agree to the use of cookies. For more information, please refer to our Privacy policy.