I welcome your efforts. You should, as a friendly member of the community, consider unleashing your operations.
1 ) Have one function / routine / class / method for filtering input ( filter_input_array() , strip_tags() , str_ireplace() , trim() , etc.). You might want to create functions that use loops for filtering. Tricks, such as double coding, one-time subtyping, and more, can defeat one use of things like strip_tags() .
Here is the strip_tags() wrapper method from my Sanitizer class. Notice how it compares the old value with the new value to see if they are equal. If they are not equal, it continues to use strip_tags() . Although, before this method is executed, quite a bit of preliminary check INPUT_POST / $ _ POST will be done. Another version of this using trim() is done before.
private function removeHtml(&$value) { if (is_scalar($value)) { do { $old = $value; $value = strip_tags($value); if ($value === $old) { break; } } while(1); } else if (is_array($value) && !empty($value)) { foreach ($value as $field => &$string) { do { $old = $string; $string = strip_tags($string); if ($string === $old) { break; } } while (1); } } else { throw new Exception('The data being HTML sanitized is neither scalar nor in an array.'); } return; }
2 ) You have one more for checking input ( filter_var_array() , preg_match() , mb_strlen , etc.)
Then when your data should switch contexts ...
A ). For databases, use prepared statements ( PDO , preferably).
B ) To return / pass user input to the browser, output it using htmlentities() or htmlspecialchars respectively.
In terms of magic quotes, it's best to just disable that in php.ini .
Now that these various constructs have their own areas of responsibility, all you have to do is control the flow of logic and data inside your handler file. This includes providing the user with error messages (if necessary) and error / exception handling.
There is no need to use htmlentities() or htmlspecialchars immediately if the data comes from an HTML form directly to the database. The data exit point is not to interpret it as executable instructions in a new context. There is no danger htmlentities() or htmlspecialchars can be resolved when passing data to the SQL query engine (so you filter and validate input and use ( PDO ) prepared statements).
However, after the data is extracted from the database tables and directly designed for the browser, ok, now use htmlentities() or htmlspecialchars . Create a function that uses a for or foreach to process this script.
Here is a snippet from my Escaper class
public function superHtmlSpecialChars($html) { return htmlspecialchars($html, ENT_QUOTES | ENT_HTML5, 'UTF-8', false); } public function superHtmlEntities(&$html) { $html = htmlentities($html, ENT_QUOTES | ENT_HTML5, 'UTF-8', false); } public function htmlSpecialCharsArray(array &$html) { foreach ($html as &$value) { $value = $this->superHtmlSpecialChars($value); } unset($value); } public function htmlEntitiesArray(array &$html) { foreach ($html as &$value) { $this->superHtmlEntities($value); } unset($value); }
You will have to adapt your code to your personal tastes and situation.
Please note that if you plan to process the data before sending it to the browser, first process it and then use the looping-dandy function using the convenient htmlentities() or htmlspecialchars function.
Can you do this!