Во-первых, я в этой теме уже 2 раза писал, что наличие этой функции - признак воняющего кода. По нескольким причинам, одна из которых - безопасность.
Потому что при использовании SQL-запросов в виде строк мы имеем наличие человеческого фактора и возможную SQL-inj из-за него.
Хочешь писать SQL запросы - используй плейсхолдеры. А можешь не писать и использовать AR или ORM.

Во-вторых, при правильной работе с СУБД SQL-inj не будет без использования каких-либо мер для обеспечения безопасности. Вобщем RTFM по вашей библиотеке для работы с СУБД.

Причина твоих заблуждений в том, что ты считаешь экранирование средством от SQL-inj, а не обеспечением правильного синтаксиса запроса.

  Я чет совсем запутался, вроде как раз от человеческого фактора на прямую зависит качество кода. Или ты имеешь в виду инструментарий?


Я бы добавил что важна ещё правильная настройка самой СУБД.

Это сообщение отредактировал(а) krundetz - 31.12.2011, 01:01

 Программист не должен использовать потенциально-опасные функции типа mysql_real_escape_string. Точка.
Потому что рано или поздно он забудет ее применить.

Поэтому едтинственный разумный вариант - не работать с SQL-запросом как со строкой.

Согласен.

Не всегда есть такая возможность. Да и если здесь не будет косяков, найдутся в другом месте. Что со всем ни с чем не работать?


Это сообщение отредактировал(а) krundetz - 2.1.2012, 20:59

 И когда ее нет? Всякие плагины-экстеншены не рассматриваем, только отдельные продукты.

 Ну в данном случае говорили про SQL-inj.
От того же XSS пока полностью защититься очень сложно и эта работа явно не на человеконеделю.