diff --git a/editorial/agent-rewrites/258.json b/editorial/agent-rewrites/258.json
index b09e640..45e0f7f 100644
--- a/editorial/agent-rewrites/258.json
+++ b/editorial/agent-rewrites/258.json
@@ -1,7 +1,7 @@
 {
   "index": 258,
   "slug": "editorial-2020-11-practice-security-baseline",
-  "title": "Старая админка без CSRF: как проверить минимальный контур защиты",
-  "excerpt": "Один state-changing маршрут показывает, где заканчивается сессия, начинаются CSRF и permission, зачем нужен CSP и чем подтверждать отрицательный путь.",
-  "contentHtml": "<p>Симптом у старой админки простой: пользователь открывает форму, нажимает «Сохранить», и профиль меняется. Но тот же маршрут принимает запрос без CSRF-токена. В логах виден только действующий сеанс, поэтому команда принимает успешный ответ за доказательство безопасности. Цена ошибки зависит от права пользователя: посторонняя страница может заставить его браузер отправить действие с cookie, а запрос с известной сессией может изменить данные без явного намерения. Для администратора это может означать смену реквизитов, добавление пользователя или изменение настроек.</p>\n<p>Тезис статьи короткий: минимальный security baseline строится вокруг конкретного state change. Сначала сервер проверяет, кого он узнал. Затем проверяет контекст формы и право на действие. Только после этого меняет состояние. Cookie-флаги и CSP дополняют этот контур, но не заменяют ни CSRF-проверку, ни серверную авторизацию. Учебный пример ниже не доказывает защиту production-системы. Он показывает модель, которую можно проверить на одном маршруте.</p>\n<h2>Где возникает ошибка</h2>\n<p>Рассмотрим учебный маршрут <code>POST /admin/profile</code>. Он меняет только <code>displayName</code>. Браузер отправляет cookie с сессией автоматически. Если сервер решает «сессия есть — разрешаем», запрос с другого сайта выглядит для него почти так же, как запрос из формы админки. Поле <code>Origin</code> помогает проверить источник, а CSRF-токен добавляет значение, которого атакующий сайт не должен знать. Эти проверки относятся к контексту формы. Permission отвечает на другой вопрос: имеет ли распознанный пользователь право менять профиль.</p>\n<p>Порядок важен. Сначала отбрасываем неподходящий метод и маршрут. Потом получаем сессию. Для HTML-формы проверяем разрешённый origin и токен. Затем проверяем <code>profile:write</code>. Функция обновления не должна вызываться до последней проверки. Если permission спрятан только в интерфейсе, любой клиент сможет обратиться к endpoint напрямую. Если токен проверяется после update, защита появляется в отчёте, но не в поведении.</p>\n<figure><img src=\"/assets/editorial/2020/security-baseline-asset-threat-control-2020.svg\" alt=\"Связь актива, угрозы, контроля и доказательства для административного маршрута\"><figcaption>Минимальный контур связывает действие с угрозой, контролем и наблюдаемым доказательством. Успешный ответ проверяет доступность функции, а отрицательные запросы проверяют границы.</figcaption></figure>\n<h2>Один маршрут и несколько независимых контролей</h2>\n<p>У сессии, CSRF, permission и CSP разные владельцы. Сессия связывает cookie с субъектом. CSRF-контроль проверяет, что state change пришёл в ожидаемом контексте. Permission ограничивает действие субъекта. CSP ограничивает ресурсы, которые браузер может загрузить на странице. Нельзя заменить permission атрибутом <code>HttpOnly</code> или закрыть XSS одной директивой CSP.</p>\n<pre><code>function updateProfile(request) {\n  if (request.method !== 'POST' || request.path !== '/admin/profile') {\n    return { status: 404, reason: 'route-not-found' };\n  }\n\n  const session = sessions.find(request.cookies.sid);\n  if (!session) return { status: 401, reason: 'unknown-session' };\n\n  if (request.origin !== 'https://admin.example.test') {\n    return { status: 403, reason: 'unexpected-origin' };\n  }\n\n  if (!csrf.verify(session.id, request.body.csrfToken)) {\n    return { status: 403, reason: 'invalid-csrf-token' };\n  }\n\n  if (!session.permissions.includes('profile:write')) {\n    return { status: 403, reason: 'insufficient-permission' };\n  }\n\n  profileStore.setDisplayName(session.userId, request.body.displayName);\n  return { status: 204 };\n}</code></pre>\n<p>Код намеренно похож на обычный серверный псевдокод. В нём нет настоящей библиотеки сессий, способа выдачи токена или базы данных. Это учебный пример: он показывает границу между проверкой и побочным эффектом. В реальном приложении токен должен генерировать и проверять поддерживаемый механизм фреймворка или отдельная проверенная библиотека. Значение из примера нельзя копировать как секрет. Также нужно валидировать и безопасно выводить <code>displayName</code>; CSRF не защищает от XSS и некорректной обработки ввода.</p>\n<h2>Симптомы и действия</h2>\n<table><caption>Проверка одного state-changing маршрута</caption><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Любой POST с cookie получает успех</td><td>Сессия принята за доказательство намерения</td><td>Отправить запрос без токена и с чужим origin на тестовом стенде</td><td>Отклонять запрос до update и добавить отрицательный тест</td></tr><tr><td>Проверка права есть только в UI</td><td>Кнопка скрывает действие, но endpoint не авторизует его</td><td>Вызвать маршрут ролью <code>profile:read</code></td><td>Проверять <code>profile:write</code> на сервере</td></tr><tr><td>CSRF включён на одной форме</td><td>Защита привязана к компоненту, а не к карте изменений</td><td>Перечислить POST, PUT, PATCH и DELETE, которые меняют состояние</td><td>Для каждого маршрута определить контекст и механизм защиты</td></tr><tr><td>После CSP страница ломается</td><td>Policy добавили без списка реальных ресурсов</td><td>Сравнить нарушения с нужными script, style, image и frame</td><td>Начать с узкой policy, исправить зависимости и только потом включать enforcement</td></tr><tr><td>В отчёте есть cookie flags, но нет факта отказа</td><td>Настройку приняли за наблюдаемое поведение</td><td>Проверить response headers и четыре ветки решения</td><td>Хранить контракт ответа и положительный/отрицательные сценарии отдельно</td></tr></tbody></table>\n<h2>Cookie и CSP не должны маскировать главную проверку</h2>\n<p>Для сессии обычно задают <code>Secure</code> и <code>HttpOnly</code>. Первый ограничивает отправку cookie HTTPS-сценарием, второй не даёт обычному JavaScript прочитать значение. Узкий <code>Path</code> может уменьшить область отправки. Но ни один из этих атрибутов не говорит, что пользователь имеет право на конкретный update. Сервер всё равно должен разобрать сессию и выполнить permission check. Для критического действия могут потребоваться повторная аутентификация или одноразовое подтверждение.</p>\n<p>CSP задаёт браузеру список разрешённых источников и может уменьшить последствия инъекции или встраивания страницы. Учебный вариант можно начать так:</p>\n<pre><code>Content-Security-Policy:\n  default-src 'self';\n  script-src 'self';\n  object-src 'none';\n  base-uri 'self';\n  frame-ancestors 'none'</code></pre>\n<p>Эта policy может сломать inline-скрипты, внешний analytics и embedded widget. Поэтому не добавляйте домены по одной ошибке в консоли. Сначала выпишите ресурсы конкретной страницы, проверьте, нужны ли они активу, и примените policy в режиме наблюдения, если это поддерживает ваша схема развёртывания. CSP не исправляет небезопасное экранирование, валидацию входа или доверие к пользовательскому HTML.</p>\n<h2>Проверяемый отрицательный путь</h2>\n<p>Положительный сценарий отвечает только на вопрос «маршрут работает». Для baseline важнее сохранить отказ там, где контроль должен сработать. На учебной среде нужны минимум четыре входа: корректная сессия, origin и токен с правом получают <code>204</code>; отсутствующий токен получает <code>403</code>; чужой origin получает <code>403</code>; роль без <code>profile:write</code> получает <code>403</code>. Не проверяйте этот пример на чужом сервисе и не используйте настоящие cookie или персональные данные.</p>\n<p>Логируйте причину отказа без токена и секретов. Для диагностики достаточно идентификатора маршрута, результата проверки и request id. Не записывайте значение CSRF-токена, session ID или полный body. Если реальный proxy переписывает заголовки, проверяйте также финальный HTTP-ответ разрешённого стенда. Unit-тест функции и проверка ответа веб-сервера доказывают разные вещи.</p>\n<h2>Порядок внедрения</h2>\n<ol><li>Назовите один актив и один маршрут, который меняет его состояние. Запишите клиентов маршрута: HTML-форма, API или интеграция.</li><li>Разделите решения: сессия, контекст формы, permission и response policy. Для каждого укажите вход, владельца и момент проверки.</li><li>Поставьте все server-side gates перед вызовом функции, которая меняет данные. Не полагайтесь на скрытую кнопку или проверку в JavaScript.</li><li>Подключите CSRF-механизм фреймворка, если он есть. Для собственной схемы отдельно опишите выдачу, срок жизни, привязку и сравнение токена.</li><li>Опишите cookie attributes и CSP для реального маршрута. Сверьте policy с ресурсами страницы, браузерами и конфигурацией веб-сервера.</li><li>Добавьте положительный тест и отрицательные тесты для пустого токена, чужого origin, неизвестной сессии и недостаточного permission.</li><li>Проверьте финальный ответ на разрешённом стенде. Сохраните только безопасные поля: статус, выбранный маршрут, тип отказа и request id.</li><li>Запишите непокрытые зоны: XSS, SQL injection, upload, CORS, rate limit, восстановление аккаунта, TLS, секреты, зависимости и сетевой периметр.</li></ol>\n<h2>Ограничения и критерий готовности</h2>\n<p>Этот baseline не является полным аудитом. Он не проверяет криптографию, конфигурацию CDN, реальный браузерный cache, доступность cookie на всех поддоменах, API-интеграции или права каждой роли. Origin может отсутствовать в некоторых допустимых контекстах, а один и тот же endpoint может обслуживать разные типы клиентов. В таком случае нельзя бездумно расширять исключения: нужно разделить контракты и описать отдельную модель угрозы.</p>\n<p>Работу можно считать готовой для одного маршрута, если документирован актив, а до изменения состояния проходят отдельные проверки сессии, контекста и permission; четыре учебных отрицательных/положительных сценария дают ожидаемые статусы; финальный ответ содержит согласованные cookie и CSP-поля; журнал не раскрывает секреты; команда явно записала непокрытые области. Это проверяемый критерий для узкого участка, а не заявление, что всё приложение защищено.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener\">OWASP: Cross-Site Request Forgery Prevention Cheat Sheet</a> — рекомендации по токенам, проверке контекста и ограничениям CSRF-защиты.</li><li><a href=\"https://owasp.org/www-project-application-security-verification-standard/\" target=\"_blank\" rel=\"noopener\">OWASP: Application Security Verification Standard</a> — официальный набор требований для проверки технических контролей веб-приложения.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy\" target=\"_blank\" rel=\"noopener\">MDN: Content-Security-Policy header</a> — синтаксис заголовка и назначение директив CSP.</li></ul>"
+  "title": "Минимальная защита старой админки: один маршрут, четыре контроля",
+  "excerpt": "Не начинаем с коллекции заголовков: для учебного маршрута связываем актив, угрозу, контроль и наблюдаемое доказательство.",
+  "contentHtml": "<p>Симптом у старой админки обычно выглядит безобидно: форма меняет профиль, сессия работает, а после релиза никто не может показать, какие условия действительно защищают это изменение. В настройке лежат несколько headers, в коде есть проверка пользователя, но связь между активом, угрозой и проверкой не записана. Цена такой неопределённости конкретна: команда может добавить ещё один заголовок, оставить state-changing маршрут без server-side permission или принять успешный ответ за доказательство, что посторонний запрос не изменит данные.</p>\n<p>В ноябре 2020 года я бы начал не с большого аудита и не с обещания «закрыть web security». Ниже — учебный маршрут <code>POST /admin/profile</code> на вымышленном origin <code>https://admin.example.test</code>. Его предполагаемый эффект — изменение synthetic display name; fixture останавливается раньше, на решении до эффекта. Цель — собрать маленький baseline: известная сессия, токен и origin для state change, permission на сервере, cookie contract и ограничивающий CSP header. Это не pentest, не security scan и не подтверждение production-защиты.</p>\n<h2>Сначала называем актив и цену ошибки</h2>\n<p>Актив здесь не «сайт вообще», а возможность изменить профиль из административной формы. Угроза — запрос приходит не в ожидаемом пользовательском сценарии или пользователь с действующей сессией вызывает действие без нужного права. Контроль — не одно условие, а несколько независимых: сервер узнаёт сессию, для формы сравнивает CSRF token и ожидаемый origin, затем проверяет permission перед побочным эффектом. Доказательство — фиксированный отрицательный сценарий, который получает <code>403</code>, и явный положительный сценарий, который получает <code>204</code>.</p>\n<p>Такое сужение важно. Cookie с <code>HttpOnly</code> полезен для ограничения доступа скрипта к значению cookie, но сам по себе не отвечает на вопрос, можно ли отправить нежелательное действие из браузера. Аналогично CSP ограничивает источники контента на стороне user agent, но не заменяет validation input, encoding output и authorisation в приложении. OWASP ASVS 4.0.2 уже был доступен в октябре 2020 года; я использую его как список проверяемых областей, а не как наклейку «соответствует стандарту».</p>\n<figure><img src=\"/assets/editorial/2020/security-baseline-asset-threat-control-2020.svg\" alt=\"Вертикальная матрица для учебной админки: активы «изменение профиля», «сессия» и «разметка страницы» соединены с угрозами, конкретными controls и наблюдаемыми evidence, включая 403 fixture и видимые response headers\" loading=\"lazy\" /><figcaption>Baseline становится проверяемым, когда каждому активу сопоставлены не только риск и настройка, но и короткое доказательство. Один header не заменяет permission, а один положительный ответ не доказывает отрицательный путь.</figcaption></figure>\n<h2>Матрица не даёт потерять границу контроля</h2>\n<div class=\"table-scroll\"><table><caption>Учебная матрица «актив → угроза → контроль → доказательство»</caption><thead><tr><th scope=\"col\">Актив</th><th scope=\"col\">Угроза в узком маршруте</th><th scope=\"col\">Контроль</th><th scope=\"col\">Что считаем доказательством</th></tr></thead><tbody><tr><td>Изменение display name</td><td>запрос проходит без ожидаемого контекста формы</td><td>сравнить <code>Origin</code> и CSRF token до update</td><td>fixture отклоняет foreign origin и пустой token с <code>403</code></td></tr><tr><td>Сессия администратора</td><td>значение cookie доступно скрипту или посылается без HTTPS-контракта</td><td><code>Secure</code>, <code>HttpOnly</code>, узкий <code>Path=/admin</code></td><td>учебная карта response headers содержит три атрибута</td></tr><tr><td>Право на изменение</td><td>аутентифицированный пользователь пишет без роли</td><td>server-side <code>profile:write</code> перед эффектом</td><td>fixture отклоняет <code>profile:read</code> с <code>403</code></td></tr><tr><td>Разметка admin page</td><td>инъекция загружает неожиданный script или объект</td><td>validation/encoding в приложении плюс CSP2 policy</td><td>в карте headers есть <code>default-src</code>, <code>object-src</code> и <code>frame-ancestors</code></td></tr></tbody></table></div>\n<p>В строке про сессию <code>Path</code> — ограничение области отправки cookie, а не граница авторизации. RFC 6265 прямо описывает механизмы Cookie и Set-Cookie; из этого не следует, что cookie attribute заменяет серверную проверку права. В строке про CSP также нет обещания «остановить XSS». W3C CSP Level 2 называет policy дополнительной защитой: сначала приложение корректно работает с input и output, затем browser получает более узкий список допустимых источников.</p>\n<h2>Один state change должен пройти через все gates</h2>\n<p>Симптом «форма сработала» ничего не говорит о порядке проверок. Причина ошибки часто в том, что разработчик смешивает наличие сессии с правом на конкретное действие. Проверка должна быть простой: до вызова функции обновления собрать method, path, session, origin, token и permission; затем явно остановить маршрут на первом неподходящем условии. Действие — оставить этот порядок рядом с кодом и не переносить его в неочевидный клиентский обработчик.</p>\n<pre><code>// Учебный псевдокод одного HTML-маршрута. Не middleware и не framework API.\nconst decision = evaluateTrainingStateChange({\n  method: &#039;POST&#039;,\n  path: &#039;/admin/profile&#039;,\n  sessionId: request.cookie.sid,\n  origin: request.header.origin,\n  csrfToken: request.form.csrf,\n  permission: request.user.permission,\n});\n\nif (!decision.allowed) return response.status(decision.status).end();\nreturn updateTrainingProfile(request.form.displayName).status(204).end();</code></pre>\n<p>Это намеренно не готовое middleware и не код какого-либо framework. В учебной форме token передаётся в body, а origin сравнивается только для одного HTML state-changing маршрута. В реальном приложении надо отдельно решить, какие клиенты существуют, когда browser посылает Origin, как выдаётся token, где хранится сессия и как API отличается от формы. Но permission всё равно остаётся серверной границей: клиентский скрытый элемент, URL и кнопка не являются доказательством права.</p>\n<h2>Headers описывают контракт ответа, а не магическую броню</h2>\n<p>Симптом у конфигурации другой: header записан в wiki, но никто не знает, на каком route и в каких ответах его ждут. Причина — security policy живёт отдельно от маршрута. Проверка — сделать маленькую карту response headers и привязать её к <code>/admin/</code>, а не включать случайный набор директив глобально. Действие — перед применением сверить syntax с версией веб-сервера, инвентаризировать фактические scripts, styles и frames, а затем проверить ответ разрешённого стенда.</p>\n<pre><code># Учебный фрагмент, не готовая конфигурация production-сервера.\n# admin.example.test — учебный origin; внешний адрес или секрет здесь не нужны.\nlocation /admin/ {\n  add_header Content-Security-Policy &quot;default-src &#039;self&#039;; script-src &#039;self&#039;; object-src &#039;none&#039;; base-uri &#039;self&#039;; frame-ancestors &#039;none&#039;&quot; always;\n  add_header Referrer-Policy &quot;same-origin&quot; always;\n  proxy_pass http://training_admin_upstream;\n}\n\n# Атрибуты cookie выставляет приложение после успешной аутентификации:\n# Set-Cookie: sid=...; Path=/admin; Secure; HttpOnly</code></pre>\n<p>В примере policy запрещает plugin content, ограничивает base URL и запрещает встраивание страницы в frame. Она также разрешает scripts только с того же origin. Это может сломать старую страницу с inline script, внешним widget или другим asset host. Поэтому фрагмент не надо копировать в production «как есть»: сначала составляют список необходимых ресурсов, фиксируют допустимый риск и проверяют выбранную версию nginx. В статье нет реального proxy, upstream или HTTP-запроса; конфигурация показывает форму контракта, а не выполненную настройку.</p>\n<h2>Короткий HTTP-след лучше общего заявления</h2>\n<p>Для маршрута полезно хранить не только код, но и один ожидаемый обмен. Симптом неопределённости — спор о том, должен ли route требовать origin, token или permission. Причина — контроль не выражен наблюдаемыми полями. Проверка — описать разрешённый учебный request и expected response headers. Действие — превратить пару в тест или безопасную ручную проверку на разрешённом стенде, когда такой стенд появится.</p>\n<pre><code>POST /admin/profile HTTP/1.1\nHost: admin.example.test\nOrigin: https://admin.example.test\nCookie: sid=training-session-42\nContent-Type: application/x-www-form-urlencoded\n\ndisplayName=Alex&amp;csrf=training-csrf-6fd2\n\nHTTP/1.1 204 No Content\nContent-Security-Policy: default-src &#039;self&#039;; script-src &#039;self&#039;; object-src &#039;none&#039;; base-uri &#039;self&#039;; frame-ancestors &#039;none&#039;\nSet-Cookie: sid=training-session-42; Path=/admin; Secure; HttpOnly\nReferrer-Policy: same-origin</code></pre>\n<p>Здесь нет реального session ID, адреса, пользователя или данных профиля. <code>admin.example.test</code> — учебный origin, а token намеренно короткий и не предназначен для защиты чего-либо вне fixture. Статус <code>204</code> означает лишь успешный исход синтетического маршрута. Нельзя из него сделать вывод, что TLS настроен, cookie реально доставляется браузером, CSP принят каждым user agent или сервер выдал headers на ошибке. Эти вопросы относятся к следующей, уже разрешённой проверке окружения.</p>\n<h2>Fixture удерживает отрицательные сценарии рядом с маршрутом</h2>\n<p>Симптом регрессии проявится, если после следующей правки один из gates перестанет участвовать в решении. Причина может быть в перестановке middleware, другом имени поля или слишком широком условии. Проверка не требует подключаться к серверу: fixture меняет по одному training input и сравнивает решение. Действие — запускать её вместе с revision и не называть результатом этой команды проверку реального browser, proxy или security perimeter.</p>\n<pre><code># В памяти: сеть, browser, proxy и scanner не запускаются.\nnode web/scripts/upgrade-2020-11.mjs --verify-fixture\n\n# Ищем не уязвимость, а сохранение учебного контракта:\n# expectedRequestAccepted=true\n# foreignOriginRejected=true\n# missingTokenRejected=true\n# insufficientPermissionRejected=true\n# cspContractPresent=true\n# sessionCookieContractPresent=true</code></pre>\n<p>В этой fixture foreign origin, пустой token и роль <code>profile:read</code> должны завершиться <code>403</code>. Успешный synthetic request получает <code>204</code>. Отдельно проверяется только наличие заданных полей CSP и Set-Cookie в объекте response contract. Если ответ на реальном стенде будет отличаться, это не повод менять fixture под сервер: сначала нужно назвать, какая граница модели отличается, и решить, расширяем ли contract либо обнаружили ошибку rollout.</p>\n<h2>Нумерованный маршрут для первой правки</h2>\n<ol><li>Выбрать один state-changing маршрут и назвать актив: какое именно состояние он меняет и кому принадлежит право на это действие.</li><li>Записать одну угрозу, которую можно проверить без атаки: foreign origin, пустой token, отсутствующая сессия или недостаточное permission.</li><li>Поставить server-side gates до побочного эффекта: session, context формы, token и permission. Не переносить permission в шаблон или JavaScript.</li><li>Собрать response contract: cookie attributes для HTTPS-сценария и CSP policy с ограниченной областью. До rollout сверить каждый directive с реальными assets и версией сервера.</li><li>Добавить положительный и отрицательные учебные сценарии. Положительный маршрут доказывает только доступность функции; отрицательные доказывают, что конкретные gates действительно останавливают запрос.</li><li>Записать verdict и исключения: нет ли API-клиентов, внешних origins, upload, персональных данных, rate limiting или другого актива, который требует отдельной модели угроз.</li></ol>\n<h2>Граница этой практики</h2>\n<p>Этот baseline не делает приложение «безопасным». Он не проверяет TLS, password storage, account recovery, file upload, SQL injection, logging, dependency vulnerabilities, rate limit, CORS, реальные браузеры или внешний сетевой периметр. Он также не запускает nginx и не утверждает, что header дошёл до production. Его результат скромнее и полезнее: для одного учебного изменения известны актив, угроза, control и evidence. Следующий инженер сможет расширить матрицу, не выдавая эту первую точку за полный AppSec-процесс.</p>\n<p>Все origin, cookies, токены, заголовки, имена маршрутов и результаты ниже учебные. Модуль не открывает сеть, не сканирует цели, не проверяет реальный сервер и не хранит секреты.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://github.com/OWASP/ASVS/releases/tag/v4.0.2_release\" target=\"_blank\" rel=\"noopener noreferrer\">OWASP ASVS 4.0.2 — релиз 28 октября 2020 года</a> — историческая версия, доступная в ноябре 2020 года; задаёт проверяемые требования, но не заменяет модель угроз конкретного приложения</li><li><a href=\"https://owasp.org/www-project-top-ten/2017/\" target=\"_blank\" rel=\"noopener noreferrer\">OWASP Top 10:2017</a> — версия 2017 года; используется как язык для разговора о рисках, а не как готовый список настроек для любого сервера</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc6265\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6265 — HTTP State Management Mechanism, апрель 2011</a> — описывает поля Cookie и Set-Cookie, включая атрибуты Secure, HttpOnly и Path; не превращает один cookie-атрибут в защиту от всех угроз</li><li><a href=\"https://www.w3.org/TR/2016/REC-CSP2-20161215/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Content Security Policy Level 2 — Recommendation, 15 декабря 2016 года</a> — историческая спецификация CSP2: политика передаётся HTTP-заголовком и является дополнительным барьером, а не заменой validation и encoding</li><li><a href=\"https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header\" target=\"_blank\" rel=\"noopener noreferrer\">nginx: ngx_http_headers_module — add_header</a> — официальная документация синтаксиса; фрагмент конфигурации применим только после сверки с версией и маршрутизацией конкретного сервера</li></ul>"
 }