Как проверять строки, спецсимволы и инъекции в тестировании

Что проверяют

Есть ли у вас системный набор неудобных строк и понимаете ли вы, что именно проверяете: сохранение, отображение или выполнение. Следом часто спрашивают, как вы убедитесь, что XSS действительно нет, а не просто «ничего не всплыло».

Как отвечать

Разделите проверки на три группы:

• длина и пустота: пустая строка, только пробелы, пробелы по краям, минимум и максимум плюс-минус один символ. Уточните, в чём система считает длину: кириллица в UTF-8 занимает два байта, эмодзи четыре;
• юникод и спецсимволы: эмодзи, в том числе составные вроде флагов, диакритика, текст справа налево, символы нулевой ширины, кавычки ' и ", обратный слеш, <, >, &, перевод строки. Ожидаемо: строка сохраняется и показывается ровно как введена, без обрезки и «кракозябр»;
• инъекции: одиночная кавычка для SQL (ответ 500 или текст ошибки базы уже сигнал), ' OR '1'='1 в поиске и логине, <img src=x onerror=alert(1)> для XSS, {{7*7}} для шаблонизаторов, ../ в именах файлов, =1+1 в полях, которые уйдут в выгрузку CSV.

Главное правило: строка должна вернуться экранированной, а не исполненной. Смотрите все места вывода: карточку, админку, письмо, экспорт. Хранимый XSS часто срабатывает там, где его никто не ждал.

Фронтенд обходите: те же строки шлите прямо в API через Postman или curl, клиентская валидация защищает только от честного пользователя. Готовые наборы строк есть в SecLists и Big List of Naughty Strings, для сканирования подойдут Burp Suite и ZAP. Всё это только на своём стенде и с разрешения.

Где спотыкаются

Проверяют одну строку '; DROP TABLE users; -- и считают тему закрытой. Инъекции ищут по реакции системы на кавычку и логические условия, а не попыткой удалить таблицу.

Смотрят вывод только там же, где вводили. Строка безопасно показывается в форме и выполняется в админке или письме.

Путают ожидания: заводят баг на то, что <b> сохранился и отобразился как текст. Это правильное поведение, баг был бы, если бы текст стал жирным.