JS JavaScript · 25 вопросов · ~70 мин · ⏱ Таймер 10:00 · Средний ·

Безопасность JavaScript-приложений

Тест проверяет XSS, CORS, CSP, безопасное обращение с недоверенными данными и расследование клиентских уязвимостей. Задания требуют выбрать защиту по контексту и понимать границы браузерных механизмов, а не искать одну волшебную настройку.

Отвечено: 0 из 25

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 25 вопросов и 70 минут; код лучше читать построчно, не полагаясь на первое впечатление. После завершения откроются общий процент, 5 тематических шкал и объяснение каждого решения.

Вопрос 1 из 25

Почему вывод параметра через innerHTML уязвим?

const name = new URLSearchParams(location.search).get("name");
greeting.innerHTML = `Привет, ${name}`;

URLSearchParams сам выполняет JavaScript во время чтения значения textContent и innerHTML одинаково интерпретируют строку как HTML Главный риск innerHTML — более медленная отрисовка текста Данные URL становятся разметкой и могут создать исполняемый контекст Опасность возникает только при наличии символа & в параметре

Вопрос 2 из 25

Как безопасно показать пользовательский комментарий без разметки?

const p = document.createElement("p");
p.textContent = comment;
container.append(p);

element.textContent = comment document.write(comment) eval(comment) element.innerHTML = comment element.outerHTML = comment

Вопрос 3 из 25

Что делать, если продукт действительно разрешает ограниченный HTML?

preview.innerHTML = sanitizeAllowedMarkup(userHtml);

Считать безопасным HTML любого пользователя после регистрации Очистить HTML проверенным sanitizer с узким списком разрешённого Заменять кавычки пробелами, сохраняя остальные теги и атрибуты Удалять только буквальную подстроку script перед вставкой Выполнять строку через eval внутри sandbox-атрибута

Вопрос 4 из 25

Почему экранирование для HTML-текста нельзя автоматически применять к JavaScript-строке или URL?

Достаточно кодировать только кавычки независимо от контекста URL-кодирование подходит и для содержимого тега script При строгой CSP контекстное кодирование уже не требуется У HTML, URL и JavaScript разные правила разбора HTML-экранирование нужно лишь серверным шаблонам

Вопрос 5 из 25

Защитит ли HttpOnly-cookie от всех последствий XSS?

HttpOnly защищает только от stored XSS, но не от reflected Да, если дополнительно у cookie установлен SameSite=Lax Да: вредоносный сценарий теряет доступ ко всем данным и действиям Нет, потому что современные браузеры больше не поддерживают HttpOnly Нет: cookie труднее прочитать, но код действует в текущей сессии

Вопрос 6 из 25

Почему Access-Control-Allow-Origin: * несовместим с credentialed-чтением ответа?

fetch("https://api.example/data", { credentials: "include" });
// Ответ: Access-Control-Allow-Origin: *

Для credentials нужен конкретный разрешённый origin, не wildcard Браузер автоматически заменяет * на значение Origin запроса HTTP запрещает отправлять cookies вместе с межсайтовыми запросами Wildcard означает тот же origin, откуда пришёл credentialed-запрос Preflight не поддерживает метод GET и поэтому отклоняет ответ

Вопрос 7 из 25

Что вызывает preflight чаще всего?

fetch("https://api.example/items/1", {
  method: "PUT",
  headers: { "Content-Type": "application/json", "X-Trace": "1" },
  body: "{}"
});

Чтение localStorage из документа текущего origin Каждый same-origin GET, даже без пользовательских заголовков Переход по обычной ссылке, если адрес содержит параметры запроса Только серверный ответ со статусом 500 на межсайтовый запрос Нес простой cross-origin запрос: PUT или нестандартный заголовок

Вопрос 8 из 25

Является ли CORS защитой серверного API от curl или вредоносного сервера?

curl -H "Origin: https://evil.example" https://api.example/private

CORS защищает от внешних клиентов только методы POST Да, если сервер отвечает на предварительный запрос OPTIONS Да, но только если API доступен исключительно через HTTPS Да: curl и серверные клиенты обязаны соблюдать браузерную политику Нет: CORS ограничивает браузер, а API всё равно проверяет права

Вопрос 9 из 25

Почему отражать любой Origin из запроса опасно?

После отражения браузер перестанет разбирать JSON в ответе Заголовок Origin содержит секрет и не должен отражаться в ответе Отражённый заголовок станет короче допустимого значения протокола Динамический Allow-Origin отключает DNS-разрешение домена Сервер фактически разрешит чтение любому сайту, особенно с credentials

Вопрос 10 из 25

Для чего Vary: Origin при динамическом Allow-Origin?

Чтобы кэш не выдал разрешение для одного origin другому Чтобы применить правила Content Security Policy к ответу API Чтобы разрешить браузеру отправлять cookies с запросом Чтобы браузер больше не отправлял предварительный OPTIONS Чтобы скрыть HTTP-статус от JavaScript вызывающей страницы

Вопрос 11 из 25

Что делает script-src с nonce?

<meta http-equiv="Content-Security-Policy" content="script-src 'nonce-r4nd0m'">
<script nonce="r4nd0m">start()</script>

Nonce изменяет атрибут SameSite у всех cookies документа Nonce шифрует исходный JavaScript перед передачей браузеру Выполняются scripts с верным nonce и другие явно разрешённые источники Директива script-src полностью запрещает сетевые fetch-запросы CSP с nonce автоматически очищает любую строку innerHTML

Вопрос 12 из 25

Почему unsafe-inline ослабляет защиту script-src?

unsafe-inline запрещает подключать внешние JavaScript-файлы Она разрешает inline-контексты только для данных JSON После неё браузер перестаёт применять правила к встроенным стилям Директива делает все cookies доступными коду страницы Она снова разрешает встроенные scripts, часто используемые XSS

Вопрос 13 из 25

Для чего режим Content-Security-Policy-Report-Only?

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'

Чтобы заменить заголовки CORS одной политикой источников Чтобы шифровать отправляемые браузером отчёты о нарушениях Чтобы безопасно разрешить eval во время настройки CSP Чтобы наблюдать нарушения без блокировки и подготовить политику Чтобы полностью отключить сбор и отправку CSP-отчётов

Вопрос 14 из 25

Какая директива управляет адресами для fetch/WebSocket?

Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.example

font-src connect-src frame-ancestors base-uri img-src

Вопрос 15 из 25

Почему CSP не должна быть единственным исправлением innerHTML-XSS?

Content Security Policy не поддерживается современными браузерами Опасный sink остаётся, а политика может быть ослаблена или обойдена CSP действует только на сервер базы данных, но не в браузере innerHTML не относится к исполняемым контекстам и не связан с CSP Наличие CSP запрещает использовать безопасный textContent

Вопрос 16 из 25

Что проверять при получении postMessage?

window.addEventListener("message", event => {
  if (event.origin !== "https://pay.example") return;
  const message = validateMessage(event.data);
  apply(message);
});

Только event.source === window Цвет iframe Точный event.origin и структуру data до использования Только event.data.length Наличие звёздочки в origin

Вопрос 17 из 25

Почему targetWindow.postMessage(secret, "*") рискован?

paymentFrame.contentWindow.postMessage(token, "*");

Wildcard означает текущий origin отправляющего документа После навигации сообщение может получить документ другого origin Символ * шифрует secret перед передачей целевому окну Метод postMessage не поддерживает передачу строковых значений postMessage работает только между документами одного origin

Вопрос 18 из 25

Как обрабатывать пользовательский redirect параметр?

const next = new URLSearchParams(location.search).get("next");
location.href = next;

Передавать параметр в eval, чтобы получить корректный URL Удалять только слово javascript, не разбирая итоговый адрес Разрешать только локальные пути или точный список origin и схем Присваивать location.href напрямую после URL-декодирования Преобразовывать строку через Boolean и использовать исходное значение

Вопрос 19 из 25

Почему скрытие административной кнопки не защищает endpoint?

if (!currentUser.isAdmin) adminButton.hidden = true;
// Endpoint /api/admin/delete всё равно доступен по сети.

Скрытую кнопку всегда можно сделать видимой через DevTools Запрос можно вызвать напрямую, поэтому право проверяет сервер Сервер определяет право по наличию элемента в DOM клиента CSS-правила кнопки автоматически передаются endpoint display:none запрещает браузеру отправлять session cookies

Вопрос 20 из 25

Чем опасно Object.assign(config, parsedUserObject) для служебного объекта?

Недоверенные ключи меняют настройки и могут затронуть прототипы После Object.assign объект теряет все унаследованные методы JSON-объекты не способны содержать собственные свойства Копирование пользовательских полей автоматически выполняет CORS Object.assign приводит свойства config к обычным записываемым полям

Вопрос 21 из 25

Как описать DOM-XSS для расследования?

const source = location.hash.slice(1);
const html = `<img alt="${source}">`;
preview.innerHTML = html;

Указать только название библиотеки, где встретился innerHTML Описать источник данных, преобразования и опасный sink Записать только браузер пользователя, приславшего отчёт Ограничиться общей фразой о том, что страница была взломана Сохранить ответ страницы и проблемный параметр, не прослеживая дальнейшие преобразования

Вопрос 22 из 25

Почему тест только со строкой <script>alert(1)</script> недостаточен?

Функцию alert нельзя вызывать внутри автоматических проверок Опасность зависит от контекста: атрибутов, URL, SVG и других форм Тег script никогда не выполняется после присваивания innerHTML Строка слишком длинна и поэтому искажает скорость теста Настоящая XSS всегда обходится без HTML-тегов

Вопрос 23 из 25

Что делать с отчётом CSP, содержащим URL страницы?

Игнорировать все CSP-отчёты, поскольку они недостоверны Сохранять полный URL в cookie каждого пользователя Выполнять содержимое отчёта как JavaScript для проверки нарушения Публиковать отчёт целиком для удобства воспроизведения Считать URL чувствительным, минимизировать данные и ограничить доступ

Вопрос 24 из 25

Как подтвердить исправление postMessage-уязвимости?

Сравнить размер сборки до и после изменения postMessage-handler Перезапустить браузер и убедиться, что вкладка открывается Удалить console.log и проверить, что ошибка больше не видна Проверить сообщения от разрешённого и чужого origin и схему данных Отправить только корректное сообщение от разрешённого origin

Вопрос 25 из 25

Какой первый шаг при обнаружении активной XSS в выпуске?

Сначала закрыть опасный путь, оценить сессии и затем исправить цепочку Тихо переименовать переменную, через которую проходит ввод Удалить тесты, содержащие уязвимые строки, из репозитория Опубликовать рабочую полезную нагрузку для всех пользователей Отключить HTTPS, чтобы упростить проверку сетевого трафика

Ответьте на все 25 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу