ReactMiddle

Веб-платформа и безопасность

Как браузер рисует страницу, DOM и события, CSS-раскладка, доступность, HTTP и кэширование, XSS, CSP и CORS, cookies, токены и OAuth, хранилища

Шпаргалка

Закрыто вопросов

0 / 23

0Повторить
15Часто спрашивают

Как тренировать тему

Шпаргалка

Вопросы

Первая цифра задаёт класс: 2xx успех, 3xx редирект, 4xx проблема с запросом, 5xx сбой на сервере. 401 означает, что сервер не знает, кто вы, а 403 означает, что знает, но отказывает; 301 означает постоянный редирект, 302 временный, а 304 сообщает, что ваша копия в кеше ещё актуальна. 2xx: 201 Created после POST; 204 No Content для сохранения или удаления без тела, поэтому res.json() на нём бросает ошибку. 3xx: 301 браузеры кешируют, а поисковики переносят страницу на новый URL; 302 не запоминается. 307 и 308 образуют ту же пару, но сохраняют метод и тело, тогда как 302 после POST обычно превращается в GET. 304 Not Modified отвечает на условный запрос и приходит без тела. 401 или 403: на 401 обновите токен или отправьте пользователя на вход; на 403 покажите «нет доступа», потому что повторный вход не поможет. Другие 4xx: 400 некорректный запрос, 404 не найдено, 409 конфликт (кто-то другой изменил запись), 422 ошибки валидации, которые показывают у полей, 429 слишком много запросов (ждите Retry-After). 5xx: 500 означает баг на сервере; 502, 503 и 504 приходят от прокси или балансировщика, когда бэкенд лежит, перегружен или медленный. Их повторяют с экспоненциальной задержкой, а большинство 4xx повторится с той же ошибкой.

HTTP/2 передаёт много запросов параллельно по одному TCP-соединению со сжатыми заголовками, а HTTP/3 переносит ту же модель на QUIC поверх UDP, поэтому один потерянный пакет больше не тормозит все потоки. Шардирование доменов теперь вредит, а число файлов больше не повод для одного большого бандла. HTTP/1.1: один запрос за раз на соединение и около шести соединений на хост, поэтому запросы стоят в очереди за медленным. Отсюда старые приёмы: один огромный бандл, спрайты, встроенные картинки, дополнительные хосты (static1., static2.). Мультиплексирование в HTTP/2: множество потоков чередуется в одном соединении, а сжатие HPACK отправляет повторяющиеся заголовки вроде cookie один раз, а не с каждым запросом. Слабое место HTTP/2: он всё ещё работает поверх TCP, поэтому один потерянный пакет задерживает все потоки, пока его не перешлют, и это заметно в мобильных сетях. Chrome убрал Server Push в 2022 году в пользу 103 Early Hints и preload. HTTP/3: QUIC восстанавливает каждый поток после потерь независимо, встраивает TLS 1.3 в рукопожатие (один round trip, ноль при возобновлении) и сохраняет соединение, когда телефон переключается с Wi-Fi на мобильную сеть. Шардирование доменов теперь вредит: каждый лишний хост стоит DNS, TCP и TLS и дробит единственное приоритизированное соединение. Бандлинг: число файлов больше не вынуждает делать один огромный бандл, но сотни крошечных модулей всё равно хуже сжимаются и требуют больше запросов. Делите код по роутам и вендорам, чтобы деплой инвалидировал меньше кеша.

Скрипт переиспользуется год без запросов; index.html сохраняется, но перепроверяется перед каждым использованием ценой ответа 304; /api/me не сохраняется никогда; список товаров берётся из кеша 60 секунд, потом ещё до 300 секунд отдаётся устаревшим, пока фоновый запрос его обновляет. **max-age с immutable**: пока ответ свежий, браузер вообще не обращается к серверу, а immutable запрещает перепроверку даже при перезагрузке. Это безопасно только потому, что хеш в имени файла меняется с каждой сборкой. **no-cache не означает «не кешировать»**: ответ сохраняется, но перед каждым использованием браузер отправляет If-None-Match: "v42". Если ETag совпадает, сервер отвечает 304 Not Modified без тела: вы платите за round trip, а не за загрузку. **no-store** и есть настоящее «не хранить»: в HTTP-кеш ничего не попадает. Его ставят на личные и чувствительные данные. private устроен иначе: браузер может сохранить ответ, нельзя только CDN и прокси. **stale-while-revalidate=300: с 60-й по 360-ю секунду после ответа устаревшая копия используется сразу, а фоновый запрос обновляет кеш; после 360 секунд следующее использование ждёт сеть. Отсутствие Cache-Control** не означает «без кеша»: при заголовке Last-Modified браузеры сами угадывают срок жизни (часто 10% от времени с последнего изменения), и так старый index.html залипает на часы. Всегда задавайте заголовок явно.

Браузер находит IP домена через DNS, открывает соединение TCP или QUIC, согласует TLS, отправляет HTTP-запрос и получает HTML. Затем он разбирает HTML, загружает CSS, скрипты и картинки, строит DOM и CSSOM и выполняет layout, paint и композитинг, чтобы показать пиксели. Сеть Сначала кеши: HSTS может поднять URL до https; service worker или свежая запись HTTP-кеша могут ответить вообще без сети. DNS: кеш браузера, кеш ОС, затем резолвер; ответом будет IP-адрес. Соединение: TCP-рукопожатие плюс рукопожатие TLS 1.3 или HTTP/3 поверх QUIC, который объединяет оба. Соединение переиспользуется для следующих запросов. Запрос и ответ: GET с cookies и заголовками; ответом может быть редирект (301, 302) или ответ с узла CDN. Рендеринг Парсер строит DOM постепенно, а preload scanner заранее начинает загружать CSS, скрипты и картинки, которые видит впереди. CSS блокирует отрисовку, классический <script> блокирует разбор. Из DOM и CSSOM получается render tree, затем layout, paint и composite дают первый кадр. DOMContentLoaded срабатывает, когда HTML разобран, load, когда загрузились все ресурсы. В SPA с клиентским рендером HTML часто оказывается пустой оболочкой, и контент ждёт, пока JS-бандл загрузится и выполнится. Эта задержка служит главным аргументом за SSR или пререндер.

CSP задаётся заголовком ответа и сообщает браузеру, какие скрипты, стили, фреймы и соединения разрешены странице, поэтому внедрённая разметка не выполнится, даже попав в DOM. Сначала включите режим report-only, переведите инлайн-скрипты на nonce или хеши и только потом включайте блокировку. Строгая политика script-src 'nonce-…' 'strict-dynamic': выполняются только скрипты со случайным nonce этого ответа и скрипты, которые они загружают. Списки разрешённых хостов (script-src cdn.example.com) слабее: любой JSONP-эндпоинт или устаревшая библиотека на разрешённом хосте становится обходом. object-src 'none' и base-uri 'none' закрывают старые приёмы внедрения, а frame-ancestors 'self' защищает от кликджекинга. Внедрение Report only: отправляйте Content-Security-Policy-Report-Only с эндпоинтом для отчётов. Ничего не блокируется, нарушения приходят в виде JSON. Собирайте их неделю-две на реальном трафике. Инвентаризация: инлайн-блоки <script> (сниппеты аналитики, скрипт темы, сериализованное состояние), атрибуты onclick="", eval в старых библиотеках и тег-менеджеры, которые подгружают ещё скрипты. Исправление: вынесите инлайн-код в файлы, поставьте nonce на оставшиеся скрипты, добавьте те сторонние сервисы, которыми действительно пользуетесь. Блокировка сначала для части трафика с включёнными отчётами, затем для всех. Nonce или хеши Nonce должен быть новым в каждом ответе, поэтому HTML приходится рендерить на каждый запрос. В Next.js заголовок ставит proxy.ts, а фреймворк сам добавляет nonce своим скриптам, но такие страницы становятся динамическими и теряют статическое и CDN-кеширование. Статический SPA на CDN не может менять свой HTML: обходитесь без инлайн-скриптов с script-src 'self' или используйте хеши ('sha256-…') немногих инлайн-скриптов, посчитанные при сборке. Следующий шаг после CSP: Trusted Types (require-trusted-types-for 'script'), с ними innerHTML и похожие точки записи принимают только очищенные значения; на 2026 год их поддерживают все основные браузеры.

Подделка межсайтового запроса (CSRF) заставляет браузер пользователя отправить запрос на ваш сайт с другого сайта, приложив cookies пользователя. Cookies с SameSite не дают браузеру прикладывать их к межсайтовым запросам; CSRF-токен доказывает, что запрос пришёл с вашей собственной страницы. Уязвима только авторизация на cookies: токен в заголовке Authorization не отправляется автоматически, поэтому API на bearer-токенах не подвержен классическому CSRF (а XSS подвержен). **SameSite=Lax**, значение по умолчанию в Chrome и Edge, если атрибут не указан, отправляет cookie при переходах верхнего уровня через GET, но не при межсайтовых POST, fetch и в iframe. **Strict никогда не отправляет её с другого сайта, поэтому пользователь, пришедший по ссылке из письма, оказывается разлогинен. None** требует Secure и нужен для настоящего межсайтового использования, например встраиваемых виджетов. Same-site не равно same-origin: evil.example.com считается тем же сайтом, что и app.example.com, поэтому скомпрометированный поддомен обходит SameSite. Токены: synchronizer token, который хранится в сессии и отправляется в заголовке или скрытом поле, или double-submit cookie; серверные фреймворки генерируют их сами. Правила: никогда не менять состояние на GET; проверять заголовок Origin или Sec-Fetch-Site у изменяющих запросов как дешёвый дополнительный слой.

Самая надёжная типовая схема: короткоживущий access-токен в памяти плюс refresh-токен в cookie с HttpOnly, Secure и SameSite, или только сессионная cookie, а токены хранит backend-for-frontend. Украсть проще всего из localStorage: любая XSS-нагрузка может его прочитать и отправить наружу. Варианты **localStorage: просто и переживает перезагрузку, но читается любым скриптом на странице, включая скомпрометированную npm-зависимость. HttpOnly cookie**: JavaScript не может её прочитать, поэтому XSS не может её скопировать; но браузер отправляет её автоматически, поэтому нужны SameSite и защита от CSRF, а API на другом origin требует CORS с credentials. Память: пропадает при перезагрузке, поэтому приложение при старте вызывает эндпоинт обновления (с cookie); XSS может пользоваться токеном, пока страница открыта, но не может его унести. Backend-for-frontend Браузер хранит только сессионную cookie; тонкий сервер держит OAuth-токены и добавляет их к запросам в API. Рекомендации IETF по OAuth для браузерных приложений называют эту схему самой безопасной. Чего хранение не исправит Пока работает скрипт атакующего, он может отправлять запросы от имени пользователя, что бы вы ни выбрали. Хранилище определяет, как долго и откуда работает украденный доступ; от самой XSS защищают CSP и экранирование вывода.

Приложение отправляет пользователя к провайдеру с хешем одноразового секрета, провайдер возвращает пользователя с короткоживущим кодом, а приложение обменивает код и исходный секрет на токены. Этот секрет (PKCE) заменяет client secret, который браузерное приложение не может хранить. Поток Старт: сгенерируйте случайный code_verifier, вычислите code_challenge = BASE64URL(SHA-256(verifier)), сохраните verifier и случайный state в sessionStorage и сделайте редирект на /authorize с response_type=code, client_id, redirect_uri, scope, state и challenge. У провайдера: пользователь входит и даёт согласие на домене провайдера; приложение никогда не видит пароль. Callback: провайдер делает редирект на redirect_uri?code=…&state=…. Приложение проверяет, что state совпадает с сохранённым, и это не даёт атакующему подсунуть свой код (login CSRF), а затем убирает код из URL. Обмен: POST /token с кодом и code_verifier. Провайдер хеширует verifier, сравнивает его с сохранённым challenge и возвращает access-токен, refresh-токен и, при OpenID Connect, id_token с описанием пользователя. Зачем PKCE SPA является публичным клиентом: всё, что лежит в бандле, включая «секрет», можно прочитать. Без PKCE код, утёкший через историю, логи или вредоносное расширение, может обменять любой, у кого он есть; с PKCE это может только владелец verifier. Старый implicit flow (response_type=token) возвращал токен прямо в URL, откуда он утекал через историю и referrer. RFC 9700 (2025) не рекомендует его использовать и требует PKCE для публичных клиентов. В продакшене Берите поддерживаемую библиотеку (oidc-client-ts или SDK провайдера), а не самописный код, и регистрируйте точные redirect URI. Refresh-токены, которые хранит браузер, должны ротироваться при каждом использовании или быть привязаны к клиенту. Backend-for-frontend может выполнять тот же поток на сервере как конфиденциальный клиент и отдавать браузеру только сессионную cookie.

Материалы

Все источники

OWASP · docs

OWASP: шпаргалка по защите от XSS

Google Chrome team · article

web.dev: Web Vitals

W3C WAI · docs

ARIA Authoring Practices: паттерны