Ниже - практичный словарь веб терминов для разработки и безопасности: DOM, SSR/CSR/SSG, hydration, CORS, CSP и JWT. Вы получите краткие определения, реальные границы применимости, типовые ошибки и безопасные шаги проверки. Формулировки - как для рабочей диагностики: что именно происходит в браузере/на сервере и где чаще всего ломается.
Кратко о спорных моментах терминологии
- SSR/CSR/SSG описывают где и когда собирается HTML, но не гарантируют ни SEO, ни скорость сами по себе - решают детали кеширования, данных и JS.
- Hydration - это не "рендер", а "подключение интерактивности" к уже готовой разметке; ошибки часто выглядят как несоответствие HTML между сервером и клиентом.
- DOM - не HTML-файл, а объектная модель в памяти браузера; производительность упирается в частоту измерений/перерисовок.
- CORS - защита браузера, а не сервера: она не мешает curl и не является полноценной авторизацией.
- CSP уменьшает риск XSS, но может "сломать" легитимный фронтенд, если политика не согласована со сборкой и CDN.
- JWT - формат токена, а не "безопасная сессия по умолчанию"; ошибки обычно в хранении, ротации и проверке claims.
| Термин | Что это простыми словами | Где выполняется | Плюс | Ограничение/риск | Быстрая проверка |
|---|---|---|---|---|---|
| CSR | HTML "достраивается" в браузере JS-ом | Клиент | Гибкость UI после загрузки | Пустой initial HTML, зависимость от JS, сложнее контролировать TTI | View Source vs Elements: разница заметна |
| SSR | Сервер отдаёт готовый HTML на запрос | Сервер + клиент | Быстрый первый контент, предсказуемый HTML | Дороже по CPU, важны кеш и защита от утечек данных | Отключите JS: контент всё ещё виден |
| SSG | HTML сгенерирован заранее на билде | Билд/CI + CDN | Дешёвая раздача, стабильность | Данные "устаревают" до регенерации, сложнее персонализация | Заголовки CDN/кеша и неизменный HTML |
| Hydration | JS "оживляет" серверный/статический HTML | Клиент | Интерактивность без повторной полной отрисовки | Mismatch, двойная работа, чувствительно к недетерминизму | Консоль: hydration mismatch warnings |
| CORS | Правила браузера для запросов к другому origin | Браузер + заголовки сервера | Контроль доступа к API из браузера | Не замена auth; частые проблемы с preflight | Network: OPTIONS + Access-Control-* заголовки |
| CSP | Политика: что можно грузить/исполнять на странице | Браузер по заголовку | Снижение риска XSS | Ломает inline-скрипты/виджеты без nonce/hash | Console: CSP violation reports |
| JWT | Подписанный токен с claims (не шифрование) | Клиент/сервер | Статус без хранения сессии на сервере | Кража токена = компрометация; нужен срок жизни и ротация | jwt.io decoder (без вставки секретов) |
Мифы о рендеринге: как отличить SSR, CSR и SSG на практике
Когда говорят про SSR CSR SSG разница, часто путают "где собран HTML" и "когда он становится интерактивным". SSR - это выдача HTML на каждый запрос (обычно с данными на сервере), CSR - сборка интерфейса в браузере, SSG - генерация HTML заранее на этапе сборки. Hydration может присутствовать и при SSR, и при SSG.
Миф №1: "SSR всегда быстрее". На практике SSR может быть медленнее при тяжёлых запросах к БД или отсутствии кеширования. Миф №2: "SSG не подходит для динамики". Подходит, если динамика вынесена в API и подгружается на клиенте, либо используется регенерация.
Безопасные шаги здесь про контроль выдачи данных: при SSR нельзя "протечь" приватными полями в HTML, а при CSR важно не раскрыть секреты в бандле. При SSG проверьте, что в статике нет персональных данных и токенов.
- Диагностика (1-2 шага): откройте DevTools → Network → Doc и сравните "View Page Source" с тем, что видите в Elements; отключите JS и обновите страницу.
DOM: структура, манипуляции и производительность
DOM это простыми словами: дерево объектов в памяти браузера, которое представляет документ (HTML) и позволяет читать/менять элементы, стили и события. HTML - это текст, DOM - результат парсинга плюс текущие изменения от JS и CSSOM-влияния на layout/paint.
Быстродействие обычно ломают не "медленные селекторы", а лишние циклы измерений и изменений: чтение layout (offset/rect) вперемешку с записью (style/class) вызывает лишние пересчёты.
- Чтение vs запись: группируйте измерения (getBoundingClientRect) отдельно от изменений (classList/style).
- Снижение перерисовок: обновляйте DOM пачкой (DocumentFragment, минимизация reflow-триггеров).
- События: используйте делегирование, чтобы не навешивать сотни обработчиков.
- Виртуализация списков: для длинных списков рендерьте видимую часть.
- Безопасность: не вставляйте непроверенный HTML через innerHTML; санитизируйте или используйте textContent.
- Диагностика (1-2 шага): Chrome DevTools → Performance: ищите длинные задачи (Long tasks) и Layout/Recalculate Style; в Console попробуйте
document.querySelectorAll('*').lengthдля грубой оценки размера DOM.
Hydration: когда он нужен и какие ошибки встречаются
Hydration нужен, когда сервер/билд уже отдал HTML (SSR/SSG), а вы хотите подключить обработчики событий и состояние UI на клиенте. По сути, фреймворк сопоставляет существующую разметку с виртуальным деревом и "пришивает" интерактивность, стараясь не пересоздавать DOM.
- SSR + SPA-логика: быстрый first paint, затем "оживление" интерфейса.
- SSG для контента: статичная статья становится интерактивной (поиск, фильтры, комменты).
- Островная архитектура: гидратируется только виджет, остальная страница статична.
- Ленивая гидратация: по видимости (IntersectionObserver) или по событию (клик), чтобы снизить нагрузку.
- Переиспользование кеша: клиент подхватывает уже загруженные данные, чтобы не мигать.
- Диагностика (1-2 шага): включите в консоли фильтр по "hydration" и проверьте предупреждения о mismatch; сравните HTML-атрибуты/текст на сервере и после загрузки (часто ломают Date/Math.random/локаль).
CORS: механика, типичные ошибки и способы отладки
CORS - это правила, по которым браузер решает, можно ли странице с одного origin сделать запрос к ресурсу на другом origin. Сервер сообщает разрешения заголовками, но применяет их именно браузер. Поэтому CORS не защищает API от запросов "напрямую" и не заменяет авторизацию.
- Что происходит: при "непростом" запросе браузер делает preflight (OPTIONS) и ожидает
Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers. - Где ограничения: нельзя использовать wildcard
*вместе сAccess-Control-Allow-Credentials: true; также важен точный origin (схема/домен/порт).
- Типовые ошибки: забыли ответить на OPTIONS; не пробросили нужный заголовок в Allow-Headers; неправильный origin в прокси/CDN; редирект на preflight; куки без SameSite/secure-атрибутов ломают сценарий с credentials.
- Безопасные шаги: разрешайте только конкретные origin; минимизируйте Allow-Headers/Methods; разделяйте публичные и приватные эндпоинты; не полагайтесь на CORS как на контроль доступа.
- Диагностика (1-2 шага): DevTools → Network: найдите OPTIONS и проверьте ответы; в терминале выполните
curl -i -X OPTIONS https://api.example.com/endpoint -H "Origin: https://site.example" -H "Access-Control-Request-Method: POST".
CSP: политика безопасности, примеры правил и обходы
Если вы спрашиваете что такое JWT CORS CSP, то CSP - самый "приземлённый" из трёх: это заголовок (или meta), который задаёт, откуда можно грузить скрипты/стили/шрифты, куда можно отправлять данные, и можно ли выполнять inline-код. CSP снижает последствия XSS, но требует дисциплины в сборке и подключении сторонних виджетов.
- Миф: "CSP = полная защита от XSS". CSP снижает поверхность атаки, но ошибки в шаблонах/санитизации остаются уязвимостью.
- Типичная ошибка: разрешить
unsafe-inline. Это часто "быстро чинит", но возвращает основной класс XSS-рисков. - Типичная ошибка: слишком широкий
script-src. Широкие домены и wildcard усложняют контроль цепочки поставки (supply chain). - Правильный путь для inline: используйте nonce или hash для конкретных скриптов, а не глобальное разрешение inline.
- Обходы в реальности: чаще не "взлом CSP", а эксплуатация разрешённых источников (скомпрометированный CDN/виджет) или JSONP/открытые редиректы в цепочке.
- Диагностика (1-2 шага): откройте Console и найдите сообщения о нарушениях CSP; проверьте заголовок
Content-Security-Policyв Network → Doc и сопоставьте его с тем, какие домены реально используются приложением.
JWT: устройство, уязвимости и правильные сценарии применения
JWT (JSON Web Token) - это компактный токен из трёх частей (header.payload.signature), где подпись защищает от подмены, но содержимое payload обычно не шифруется. JWT удобен для передачи утверждений (claims) между сервисами, но требует аккуратных сроков жизни, ротации и хранения.
- Ограничения и риски: кража токена (XSS, утечки логов, localStorage) даёт атакующему доступ до истечения срока; сложности с отзывом токенов без state; ошибки проверки алгоритма/issuer/audience.
- Безопасные шаги: короткий
exp; проверкаiss/aud; ротация ключей (kid + keyset); хранение в httpOnly cookie для браузерных сценариев, если подходит модель.
- Диагностика (1-2 шага): на сервере логируйте причину отказа в валидации (без токена целиком); локально декодируйте только header/payload без секретов и проверьте наличие
exp,aud,iss.
Мини-кейс (практическая иллюстрация): API принимает JWT в заголовке Authorization. Безопасный минимум - валидировать подпись и базовые claims, а затем авторизовать доступ по ролям/правам.
// псевдокод
token = getHeader("Authorization").replace("Bearer ", "")
claims = verifyJWT(token, keyset, {alg: "RS256", iss: "https://auth.example", aud: "api.example"})
if claims.exp < now(): deny(401)
if not claims.sub: deny(401)
user = loadUser(claims.sub)
if not user or user.disabled: deny(403)
if not hasScope(claims, "orders:read"): deny(403)
return ordersList(user.id)
Частые сомнения - короткие разъяснения
Это страница типа "словарь веб терминов" или тут есть практическая часть?
Это словарь веб терминов с практической диагностикой: для каждого понятия есть короткая проверка и типовые ограничения, чтобы быстро понять, что именно у вас используется и где искать проблему.
Можно ли объяснить веб термины простыми словами без потери смысла?
Да, если фиксировать границы: где выполняется код, что выдаётся по сети и кто применяет правило (например, CORS - именно браузер). Тогда упрощение не превращается в миф.
Почему "View Source" и "Elements" отличаются при CSR и hydration?
"View Source" показывает исходный HTML ответа, а "Elements" - текущий DOM после работы JS. При CSR разница обычно максимальная; при SSR/SSG с hydration DOM чаще совпадает, но становится интерактивным.
Hydration нужен всегда при SSR?
Нет. Если страница полностью статична, можно обойтись без hydration и оставить чистый HTML. Hydration нужен, когда требуются события, состояние и интерактивные компоненты.
CORS - это способ закрыть API от чужих клиентов?
Нет. CORS лишь ограничивает, какие браузерные страницы могут читать ответы. Закрывать API нужно авторизацией, проверкой токенов и серверными правилами доступа.
CSP может заменить санитизацию пользовательского ввода?
Нет. CSP снижает вероятность успешного XSS, но не устраняет уязвимость в источнике. Санитизация/экранирование и безопасные шаблоны остаются обязательными.
JWT безопасно хранить в localStorage?
Это рискованно при наличии XSS: скрипт может прочитать токен. Для браузерных приложений часто безопаснее httpOnly cookie (при корректных SameSite/Secure и CSRF-защите), либо архитектура, где токен не доступен JS.