Symfony2 Application Security Guidelines

Symfony2 Application Developer Security Guidelines

Author: Ubani Balogun

This developer guide builds off of the official Symfony Getting Started Guide [1] and highlights the best practices that ensure security in Symfony2 web applications. It discusses the tools and techniques the Symfony Framework recommends for preventing common security vulnerabilities like cross site scripting (XSS), cross site request forgery (CSRF), SQL injection, authentication bypass, etc. Following the recommendations in this guide is the easiest, most reliable way to develop and manage secure applications using the Symfony Framework.

Prevent Cross Site Scripting by Using the Twig Templating Engine

Cross Site Scripting (XSS) vulnerabilities manifest in web applications when user supplied/dynamic content is rendered in HTML templates without proper sanitization. These vulnerabilities allow a malicious user to inject and execute arbitrary script that may compromise the information stored in, as well as security and usability of, your application and its users. To protect against cross site scripting, it is necessary to ensure that all user supplied data is appropriately sanitized before being rendered as HTML.

The Symfony Framework protects against cross site scripting via the pre-installed Twig templating engine. By default, the Twig templating engine sanitizes all user supplied content before rendering the output as HTML.[2]

Although The Symfony Framework also supports the use of PHP templates, PHP templates do not provide the default protection against cross site scripting as Twig templates do. PHP templates require the developer to implement explicit filtering of user output. This solution is suboptimal as it requires manual code addition which can lead to oversights.  Additionally this solution can introduce vulnerability later on in the application life cycle if a future developer does not assume the responsibility of filtering output. Therefore, the most reliable approach to protecting against cross site scripting in Symfony applications is to use the Twig templating engine. Learn more about the Twig templating engine at http://twig.sensiolabs.org/documentation

Ensure Form Security by Using Symfony's Form Builder

The Symfony Framework's Form Builder class is an easy and reliable approach to handling the security challenges that forms present in web applications. It provides methods for:

  • Creating and rendering form elements correctly
  • Protecting against cross site request forgery vulnerabilities
  • Server side validation of user input
  • Handling user submissions

In Symfony, Forms created and rendered using the Form Builder class automatically provide protection against cross site request forgery (CSRF); a security vulnerability that allows an attacker to force a legitimate user into unknowingly submitting data and performing actions that can lead to information exposure and site compromise [3]. The Form Builder class protects against CSRF this by automatically embedding CSRF tokens in forms when they are rendered using the Twig templating engine in accordance with the Symfony documentation [4]. Creating and rendering forms without using the Form Builder class puts your Symfony application at risk of exposing cross site request forgery vulnerabilities.

In addition to protecting against cross site request forgery, the Symfony framework also provides easy, reliable methods for implementing server side validation of form input using the Form Builder class. Using the form validators provided by Symfony verifies the integrity of the data supplied to your application's database. This goes a long way in ensuring the safety and usability of your application. It is important to note that relying on client side validation alone is insufficient in protecting your application's data as such protections can be bypassed.

The ideal method for handling form submission requests in Symfony is through the Form Builder class. Handling submissions through the Form Builder class ensures that form validation and CSRF protection are applied correctly.

To learn more about creating forms securely in Symfony, visit http://symfony.com/doc/current/book/forms.html

Defend against SQL injection Using the Doctrine ORM

The Symfony Framework comes integrated with the Doctrine ORM to facilitate secure database interactions for your application. Using the Doctrine ORM correctly protects your application from SQL injection vulnerabilities. Correct usage entails:

  • Defining objects, referred to as Entities in Symfony, that map to your database tables, and using Doctrine's API for interacting with database tables.
  • Building database queries correctly by using Doctrine's Query Builder and replacing external values with place holders, i.e. parametized queries
  • Using Doctrine APIs that have been designated as safe
  • Refraining from making native SQL queries or interacting with the database layer directly

The Symfony documentation provides an example of how to use the Doctrine ORM correctly at http://symfony.com/doc/current/book/doctrine.html#a-simple-example-product

The use of parametized queries is explained at http://symfony.com/doc/current/book/doctrine.html#querying-for-objects

Learn about Doctrine ORM's secure APIs at http://doctrine-orm.readthedocs.org/en/latest/reference/security.html

Use Symfony's Security Bundle to Implement Access Control, Authentication, Session Management and Firewalls

The Symfony Framework's Security Bundle is the most reliable method for managing authentication, user sessions, access control and firewalls in your Symfony application. Using the Security Bundle entails declaring security configurations in a configuration file. The full default security configuration for Symfony applications can be reviewed at http://symfony.com/doc/current/reference/configuration/security.html. Although your security application may not override all configurations, it is important to acquaint yourself with the security options Symfony provides out of the box.

To understand the Symfony Framework security architecture, visit http://symfony.com/doc/current/book/security.html, paying special attention to the common pitfalls sections (http://symfony.com/doc/current/book/security.html#book-security-common-pitfalls).

Attempting to write custom/native php code to handle authentication, session management, access control or firewalls can lead to authentication bypass vulnerabilities in your application.

Delete Unnecessary Code

The Symfony Framework installs with the AcmeDemoBundle; a demo application designed to introduce Symfony developers to the Framework's architecture and usage. Do not develop your Symfony application by extending or modifying the demo application. Once you have completed developing your Symfony application, delete the demo application by following the guidelines at http://symfony.com/doc/current/cookbook/bundles/remove.html

Additionally all debugging messages and code should be removed.  This includes code that has been commented out or is no longer being used.  Extraneous code can introduce unforseen issues affecting stability and security.  Debugging messages can be used by adversaries to glean information about the site that can be used in an attack.

Review Third Party Bundles

The Symfony Framework allows developers extend their application through the use of third party bundles. While convenient, third party bundles may introduce security vulnerabilities into your application. The easiest way to prevent this scenario is to request a code review of the bundle by SAS Information Security prior to installation, ensuring it conforms to the security recommendations in this guide.


[1]: http://symfony.com/doc/current/quick_tour/the_big_picture.html "Symfony, The Quick Tour"
[2]: http://symfony.com/doc/current/book/templating.html#output-escaping "Output Escaping, Symfony"
[3]: http://symfony.com/doc/current/book/forms.html#csrf-protection "CSRF Protection, Symfony"
[4]: http://symfony.com/doc/current/book/forms.html#rendering-a-form-in-a-template "Rendering a Form in a Template, Symfony"