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
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
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 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!
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.
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
Because of the bootstrap architecture (=every request is handled by a single php file) requests
like /content.php?seite=http://casts.150m.com/expo/expo1? cannot affect the operation
of the application.
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 article
(German) or in the German language forum under
website http://phpsec.org 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.