By the Request ( source ) > and consequently ParameterBag , can be used in the following way that you already have what you expect :

$id = $request->request->getInt('id'); 
$nm = $request->request->getAlpha('name');
$st = $request->request->getBoolean('status');

$mail = $request->request->filter('id', 0, FILTER_SANITIZE_EMAIL);

In the mentioned case all() , the data is not treated, but as it was reported there is an option where it can be done with filter or implemented getInt , getAlpha , getBoolean , getDigits and getAlnum that internally use this type of code, example getBoolean :

public function getBoolean($key, $default = false)
{
    return $this->filter($key, $default, FILTER_VALIDATE_BOOLEAN);
}

The Doctrine - Security has a security feature, but this can be complemented with the code exemplified above, or even a Validation Class , can bar most problems encountered in Web development with data obtained through requests link .

References:

• Request
• ParameterBag
• 34. Security - Doctrine

Completing @Virgilio Novic's response, which tells documentation of Doctrine:

  

In general you should assume that APIs in Doctrine are not safe for user input. There are however exceptions.

Free translation:

  

In general, you should assume that the APIs in Doctrine are not safe for user inputs. There are, however, some exceptions.

Exceptions can be seen at the following links:

• SQL Injection: Safe and Unsafe APIs for User Input)
• User input and Doctrine ORM .

Notice what the section says 12.2.1. Wrong: String Concatenation (string concatenation), you should never ever build your queries dynamically and concatenate user inputs in your SQL or DQL query. For Doctrine there is absolutely no way to find out which parts of SQL are user inputs and which are not.

For example:

<?php
$sql = "SELECT * FROM users WHERE name = '" . $_GET['username']. "'";

Although DQL is a wrapper around SQL that can protect against some security implications, the previous example is also a threat to DQL queries, which in the end will result in a query:

$dql = "SELECT u FROM User u WHERE u.username = '" . $_GET['username'] . "'";

In this scenario, an attacker could still pass a user name set to 'OR 1 = 1 and create a valid DQL query.

So how do you make queries safer?

• Prepared Statements : you should always use it to run your queries. It is a two-step procedure separating the SQL query from the parameters. They are supported for DBAL SQL queries and DQL ORM queries.

DQL Example:

$dql = "SELECT u FROM User u WHERE u.username = :name";
$query = $em->createQuery($dql);
$query->setParameter("name", $_GET['username']);
$data = $query->getResult();

SQL Example:

$sql = "SELECT * FROM users WHERE username = ?";
$stmt = $connection->executeQuery($sql, array($_GET['username']));

See more information on how to use it here .

• Quoting / Escaping : Although I previously said that string concatenation is wrong, there is a way to do it correctly using the Connection#quote method. This method is available only for SQL, not for DQL. For DQL it is always encouraged to use Prepared Statements not only for security, but also for cache reasons.

Example:

$sql = "SELECT * FROM users WHERE name = " . $connection->quote($_GET['username'], \PDO::PARAM_STR);

Data received via Request using Doctrine need to be handled?

Depends on which API is being used as referenced in documentation, but generally if the query is being constructed based on user input, yes, / p>