This tutorial is aimed to introduce the reader to PHP filters from OWASP. OWASP (Open Web Application Security Project ) released a top ten list for web application security vulnerabilities in 2003 and 2004; you can find the latest information about their Top Ten Project here.
Most of the top ten vulnerabilities including (A1) Unvalidated Input, (A2) Broken Access Control, (A4) Cross Site Scripting (XSS) Flaws, and (A6) Injection Flaws, can be avoided by using these filters.


We will be using the file Rename this to and we will use it from here on. Place it into a folder in the www root of your webserver with PHP installed.
Create a .php file with this code and save it into the same folder as
    PHP: <?php


    $Test = "This is a test string";
    $Flags = PARANOID;

    echo $Test;

    //echo sanitize($Test, $Flags);

View the file you created in your browser. The output should be "This is a test string". If that is the output, then we are ready to begin using the filters.
The first filter is the PARANOID filter. Comment ("//") the "echo $Test;" line and uncomment the other two. View the page, and you will notice that the output string is now different. This is because we used our sanitize function. The syntax for the function is "sanitize($String, $Flags)". PARANOID was our flag. You can replace this with SQL, SYSTEM, HTML, INT, FLOAT, LDAP, or UTF8, all of which have different sanitization capabilities.



This will return a string containing only alphanumeric values. This is very strict and will remove anything that isn't a number or letter.


Returns a string with slashed out quotes. This is to be used for strings being entered in SQL queries, because single quotes can lead to a MySQL injection. (OWASP A1, A6)


Returns a string without special characters and wrapped in quotes. This is for strings being used for system commands. If you wrote a PHP web frontend for a command line tool such as nmap and used a string from a form for command line arguments, an attacker could use it to specify arguments to compromise your system. (OWASP A1, A5, A6, A9)


Returns a string with HTML replacements for special characters. This allows HTML to be shown on screen instead of interpreted, and prevents XSS attacks. (OWASP A4)


Returns only an integer/float without any extraneous characters. This prevents bad characters from being used where integers or floats are expected. (OWASP A1)


Returns a string sanitized for LDAP queries and prevents injection. (OWASP A1, A6)


Decodes utf-8 encoding which is used to bypass filters. (OWASP A1)
Boolean Check Function
If all we want to do is test a string instead of changing it and return a boolean, we use the check() function. check() has the same syntax as sanitize.
PHP: <?php


    $Test = "' OR ''"; //SQL injection attempt
    $Flags = SQL //SQL sanitization flag

    if(check($Test, SQL)){ //Is $Test sanitized?
    echo 'yes';} //Yeah it is
    else echo 'no'; //No it isn't
The if statement receives a boolean value from the check() function, if $Test is sanitized or not. $Test is not sanitized, and will echo "no".

Combining Filters

In the source of the OWASP file, is the following set of lines:
    define("PARANOID", 1);
    define("SQL", 2);
    define("SYSTEM", 4);
    define("HTML", 8);
    define("INT", 16);
    define("FLOAT", 32);
    define("LDAP", 64);
    define("UTF8", 128);
If you were to replace PARANOID with 1 in the sanitize function, you would get the same results. To combine filters, we can add them together.

    PHP: <?php


    $Test = "<script>' or ''</script>";//XSS and injection attack
    $Flags = HTML + SQL; //Add 2 filters to sanitization


    echo sanitize($Test, $Flags);

This will return "<script>' or ''</script>", which will not be interpreted but will render as "<script>' or ''</script> ". It is now "safe" to query a database with that variable, and also display it to the screen.
These filters take a large chunk of the sanization work out for you, but there is still the issue of string length. With PHP, the substr function will take care of that. These filters are hardly a end-all solution, but they provide a good drop-in solution that will be strengthened by other developers. Good luck and safe filtering!
This article originally appeared on