Что значит передача данных в query параметрах
Что проверяют
Понимаете ли, как устроена строка запроса, и умеете ли строить на ней проверки: кодирование, повторы, границы, влияние на кэш и на логи. Вопрос на тест-дизайн, а не на определение.
Как отвечать
Query параметры это часть URL после знака вопроса, набор пар вида ключ=значение, разделённых амперсандом. Они видны в логах сервера, в истории браузера и в заголовке реферера, поэтому пароли и токены туда не кладут даже поверх HTTPS.
Что проверять тестировщику:
- кодирование: пробел, кириллица,
&,=,+,%внутри значения должны быть закодированы процентами, иначе значение обрежется или склеится с соседним; - повторяющиеся ключи вида
?id=1&id=2: поведение не задано жёстко, разные фреймворки берут первый, последний или собирают список, а расхождение между прокси и приложением это известный класс уязвимостей; - пустое значение, отсутствующий параметр и ключ без знака равенства это три разных случая, дефолты у них могут отличаться;
- регистр ключей, порядок параметров, лишние неизвестные параметры: приложение должно их игнорировать, а не падать;
- границы и типы: отрицательное и дробное там, где ждут целое, очень длинная строка, буквы вместо чисел;
- безопасность: инъекции в фильтрах и сортировке, чужие идентификаторы в параметрах.
Отдельно посмотрите на кэширование: параметры входят в ключ кэша, поэтому рекламные метки плодят копии одной страницы, а канонический адрес должен остаться один.
Где спотыкаются
Путают query и путь. Идентификатор ресурса обычно живёт в пути, строка запроса отвечает за фильтрацию, сортировку и постраничность; проверка на смешение этих ролей находит и ошибки маршрутизации, и дыры в доступе.
Второе: ссылаются на предел длины адреса как на стандарт. В протоколе такого предела нет, ограничение задают сервер и прокси, и мерить его надо на своём стенде, а не по цифре из статьи.
Третье: проверяют только через интерфейс. Браузер кодирует значения сам, поэтому сломанная обработка кодирования видна лишь в запросе, собранном руками.