Значение передают отдельно от команды
Подготовленный запрос задаёт шаблон SQL с местами для параметров. Само значение передают при выполнении, вместо того чтобы вставлять его напрямую в текст команды. В PDO для этого используют подготовку через prepare и выполнение через execute. Представим поиск книги по названию. Текст, введённый посетителем, является искомым значением. Он не должен определять устройство запроса или становиться частью его команд. Поэтому разработчик заранее задаёт условие поиска, а название передаёт параметром. Это не означает, что можно вообще забыть о входных данных. Например, приложению всё равно нужны понятные ограничения длины строки и правила обработки пустого поиска. Такие проверки определяют допустимое поведение интерфейса. Отделение параметров решает другую задачу: сохраняет границу между данными и структурой запроса.
Название столбца не является обычным параметром
Места для параметров представляют значения данных, а не произвольные части SQL. Нельзя просто передать имя столбца для сортировки таким же способом, как название искомой книги. Направление сортировки также относится к устройству команды. Если интерфейс предлагает сортировать по названию или дате, безопаснее сопоставить эти два выбора с заранее заданными разработчиком вариантами. Любой неизвестный вариант отклоняют либо обрабатывают по явно установленному правилу. Пользователь не получает возможность произвольно задавать текст этой части запроса. Такое сопоставление проще проверять, чем попытку удалить из произвольной строки все подозрительные символы. Разработчик знает полный набор допустимых вариантов и может проверить каждый. При добавлении новой сортировки расширяется именно этот перечень, а не возможность вставлять любой текст.
Безопасный запрос ещё не подтверждает право доступа
Допустим, приложение показывает личные черновики пользователя. Запрос может быть корректно подготовлен, но всё равно вернуть чужой документ, если приложение проверяет только его номер. Защита от вмешательства в SQL не отвечает на вопрос, имеет ли текущий пользователь право читать выбранную запись. Проверку полномочий выполняют для каждого соответствующего обращения. В учебном примере нужно связать запрос с пользователем и принятой моделью доступа, а затем проверить результат для разрешённого и запрещённого случаев. Сам факт успешного входа в приложение не означает право на любой объект. Таким образом, полезно раздельно проверять три свойства: значения передаются параметрами, изменяемая структура ограничена известными вариантами, доступ к данным соответствует полномочиям. Ошибка в одном из этих мест не исправляется автоматически правильным решением в другом.
Попробуйте на практике
Спроектируйте на бумаге поиск по вымышленной личной библиотеке. Пользователь задаёт название и выбирает сортировку по названию или дате добавления. Выполнять запросы к настоящему сервису не требуется.
- Разделите входные сведения на искомое значение и выбор устройства запроса. Объясните, что можно передавать параметром.
- Опишите сопоставление двух разрешённых вариантов сортировки и поведение при неизвестном варианте.
- Добавьте правило, по которому пользователь видит только разрешённые ему записи библиотеки.
- Составьте три проверки: обычное название, неизвестная сортировка и запрос записи без необходимого разрешения.
Как проверить результат. В проекте название передаётся как значение, сортировка выбирается из ограниченного перечня, а право чтения проверяется отдельно. Подготовленный запрос нигде не объявлен заменой всех остальных мер.
Частые вопросы
Достаточно ли убрать кавычки из пользовательского текста?
Нет. Такой подход может испортить корректные данные и не даёт надёжного разделения команды и значения. Для значений используют параметризованные запросы.
Нужно ли вручную заключать передаваемый параметр в SQL-кавычки?
Нет. Значение передают через предусмотренный интерфейс привязки параметров. Детали типов и поддерживаемых возможностей проверяют по используемому драйверу базы данных.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.