Универсальная защита от xss-атак и sql-инъекций

Я не занимаюсь технической поддержкой сайтов, но так уж сложилось, что ко мне часто обращаются за помощью. С одной стороны отказывать неудобно, да и не выгодно с коммерческой точки зрения, с другой за большое спасибо в магазине тоже не расплатишься. Поэтому я решил написать универсальное решение, но столкнулся с некоторыми проблемами.
Суть решения заключается в том, чтобы отловить данные POST, GET, COOKIE и обработать их еще до того, как сайт произведет с ними какие-либо действия.
Вот собственно сам код

$jsxss="onabort,oncanplay,oncanplaythrough,ondurat ionchange,onemptied,onended,onerror,onloadeddata,o nloadedmetadata,onloadstart,onpause,onplay,onplayi ng,onprogress,onratechange,onseeked,onseeking,onst alled,onsuspend,ontimeupdate,onvolumechange,onwait ing,oncopy,oncut,onpaste,ondrag,ondragend,ondragen ter,ondragleave,ondragover,ondragstart,ondrop,onbl ur,onfocus,onfocusin,onfocusout,onchange,oninput,o ninvalid,onreset,onsearch,onselect,onsubmit,onabor t,onbeforeunload,onerror,onhashchange,onload,onpag eshow,onpagehide,onresize,onscroll,onunload,onkeyd own,onkeypress,onkeyup,altKey,ctrlKey,shiftKey,met aKey,key,keyCode,which,charCode,location,onclick,o ndblclick,oncontextmenu,onmouseover,onmouseenter,o nmouseout,onmouseleave,onmouseup,onmousemove,onwhe el,altKey,ctrlKey,shiftKey,metaKey,button,buttons, which,clientX,clientY,detail,relatedTarget,screenX ,screenY,deltaX,deltaY,deltaZ,deltaMode,animations tart,animationend,animationiteration,animationName ,elapsedTime,propertyName,elapsedTime,transitionen d,onerror,onmessage,onopen,ononline,onoffline,onst orage,onshow,ontoggle,onpopstate,ontouchstart,onto uchmove,ontouchend,ontouchcancel,persisted,javascr ipt";
$jsxss = explode(",",$jsxss);
foreach($_POST as $k=>$v)
{
if(is_array($v))
{
foreach($v as $Kk=>$Vv)
{
$Vv = preg_replace ( "'<script[^>]*?>.*?</script>'si", "", $Vv );
$Vv = str_replace($jsxss,"",$Vv);
$Vv = str_replace (array("*","\\"), "", $Vv );
$Vv = strip_tags($Vv);
$Vv = htmlentities($Vv, ENT_QUOTES, "UTF-8");
$Vv = htmlspecialchars($Vv, ENT_QUOTES);
$_POST[$k][$Kk] = $Vv;
}
}
ELSE
{
//Сначала удаляем любые скрипты для защиты от xss-атак
$v = preg_replace ( "'<script[^>]*?>.*?</script>'si", "", $v );
//Вырезаем все известные javascript события для защиты от xss-атак
$v = str_replace($jsxss,"",$v);
//Удаляем экранированание для защиты от SQL-иньекций
$v = str_replace (array("*","\\"), "", $v );
//Экранируем специальные символы в строках для использования в выражениях SQL
$v = mysql_real_escape_string( $v );
//Удаляем другие лишние теги.
$v = strip_tags($v);
//Преобразуеv все возможные символы в соответствующие HTML-сущности
$v = htmlentities($v, ENT_QUOTES, "UTF-8");
$v = htmlspecialchars($v, ENT_QUOTES);
//Перезаписываем GET массив
$_POST[$k] = $v;
}

}
Тоже самое я сделал по аналогии с _GET и _COOKIE
Основные недостатки.

1) У меня так и не вышло обработать, а точнее перезаписать их внутри функции и передать _POST, _GET и _COOKIE в качестве переменных, а главное, как следствие, обработать многомерные массивы данных рекурсивно. Соответственно $_POST[][], $_POST[][][] и тд уже обработать не выйдет и каждый такой массив надо вставлять отдельно. Массив может быть бесконечно большой, а код получится бесконечно громозкий.

2) Не охота убирать функцию mysql_real_escape_string ведь никогда не знаешь, где ее забыли упомянуть, но возникает проблема излишнего экранирования символов.

3) strip_tags удаляет все теги. Мне бы не хотелось убирать все, а лишь самые опасные теги, но беда в том, что в дополнительных параметрах можно указать только теги, которые нужно оставить. Конечно, можно использовать регулярные выражения, но к сожалению, нет уверенности в том, что не забудешь что-нибудь важное, поэтому если у кого-то есть отличная замена этому, то предлагаю собрать все в кучу и избавиться от strip_tags

4) Ну и жду других советов по данному вопросу.

Моё имхо в данном вопросе:

1. Обрабатывать всё на уровне $_POST/$_GET - совсем не выход, так как всегда бывают исключения. Безопасность продукта должна закладываться в момент написания кода. Жаль что так не всегда делают.
2. Об исключениях - с тем же хтмл, почему бы не разрешить пользователям безвредные теги форматирования. Но при этом нужно на выходе всегда вырезать лишние теги из текстов, вводимых пользователями. Дополнительно можно валидировать на входе.
3. Защита от SQL-инъекций должна делаться там, где данные вставляются в базу. Не все что приходит в посте сразу идет туда. Поэтому и говорю что безопасность должны делать те кто делал сайт.
4. Фреймворки и разные профессиональные обертки - наше все. Хорошая обертка для работы с базой (не обязательно ORM, любая библиотека вида "query builder") сама очищает все входящие параметры. Но опять-таки, если её не использовали изначально...

В общем-то, я не вижу способа сделать универсальную систему защиты для любого сайта, так как неизвестно какие будут особенности и куда и как данные идут.

UPD: Давно не писал на php, последнее время на node и все как-то SPA. В случае с нодой просто использовать knex (обертка для работы с бд), не вставлять пользовательского ввода напрямую в knex.raw - и с sql все будет хорошо. Для очистки HTML - на фронте фреймворк по умолчанию экранирует хтмл, где нужно не экранировать - используется библиотека sanitize-html с кастомными настройками (разрешены только теги форматирования). Есть другие проблемы безопасности в современном мире - например некоторые гении не проверяют на бэкэнде что пользователь запрашивает свой ресурс, а не чужой. И вторая - вредоносный код в сторонних библиотеках, которым аудит обычно никто не проводит (так как некогда, их и используют ради экономии времени)

UPD2:

Для пхп нашел https://htmlpurifier.org/, должно помочь