Збірка командного продукту і гігієна вебформ

Чотирнадцять уроків перетворюються на один продукт

Сьогодні команда зводить усе зроблене за модуль в один сайт і доводить його форми до стану, у якому їх не соромно віддати на злом сусідній команді

У кожного з вас на сервері лежить купка окремих сторінок. Книга з теми 1. Дашборд із теми 3. Опис AI-медіа з теми 4. Бот із теми 7. Журнал автоматизації з теми 6.

Кожна з них працює. Але працює вона тільки тоді, коли ти сам знаєш її адресу й сам її відкриваєш. Така окрема готова штука зветься артефактом.

З продуктом усе інакше. У нього є один вхід і спільна навігація. Є головна сторінка, яка за десять секунд пояснює чужій людині, що це й для кого. І є документація, за якою чужа людина знайде потрібне без вас. Саме цю різницю ви сьогодні й закриваєте.

Чого навчишся за цей урок

• зводити п'ять окремих сторінок в один сайт з однією навігацією;
• писати README.md так, щоб чужа людина знайшла потрібне без вас;
• пояснювати, як чужий сайт може надіслати запит від імені твого відвідувача;
• ставити у форму приховане поле, без якого сервер запит не прийме;
• проганяти форму через шість перевірок і бачити на екрані код відмови.

Хід уроку

Слова CSRF, honeypot і «відповідальне розкриття» поки нічого не означають. Розберемо кожне на своєму місці.

Що команда зробить за 120 хвилин

1. домовиться про ролі так, щоб ніхто нікого не блокував;
2. складе карту продукту: п'ять компонентів, у кожного власник;
3. опублікує все на спільному 91.219.61.4/s/team-<N> під однією навігацією;
4. напише README.md (архітектура + ролі) і SECURITY.md (куди писати про вразливість);
5. розбереться, що таке CSRF — це головна нова тема уроку;
6. додасть у кожну форму CSRF-токен, honeypot, серверну валідацію й ліміт частоти;
7. прожене чек-лист готовності з 15 пунктів і закриє всі блокуючі.

Три речі, які роблять із набору сторінок один продукт

Спільна навігація, один стиль і головна сторінка, яка пояснює себе за десять секунд

1. Спільна навігація — той самий блок на кожній сторінці

Найпоширеніша помилка збірки одна: навігація є тільки на головній. Гість заходить у /bot/ за прямим посиланням — і не бачить, куди йти далі. Про решту чотирьох блоків він просто не дізнається. Правило просте: з будь-якої сторінки продукту видно всі інші.

<header class="site">
  <a class="brand" href="/">Команда 3 · Шкільний медіацентр</a>
  <nav>
    <a href="/book/">Книга</a>
    <a href="/dash/">Дашборд</a>
    <a href="/media/">AI-медіа</a>
    <a href="/bot/">Бот</a>
    <a href="/events/">Автоматизація</a>
  </nav>
</header>

Зверніть увагу на шляхи від кореня: /book/, а не ../book/. Такий шлях зветься абсолютним. Відносний ламається, щойно сторінку перекладуть на рівень глибше. І ламається тихо, без жодного повідомлення про помилку.

2. Один стиль — одна таблиця, а не п'ять

Якщо кожен лишить свій CSS, вийде п'ять різних сайтів в одній рамці. Домовтеся про один файл /team.css. У ньому кольори, шрифт, шапка й вигляд форм.

Особисті стилі блоку кладуть окремим файлом, після спільного. І тільки на те, що справді унікальне саме для цього блоку.

3. Головна, яку розуміє чужа людина

Уявіть, що на сторінку зайшов учитель фізики. Про ваш модуль він не знає нічого. За десять секунд він має зрозуміти три речі: що це, для кого і що тут можна відкрити просто зараз.

«Проєкт учнів 10-Б» не відповідає на жодне з них. А ось так — відповідає: «Медіацентр школи: розклад заходів, бот-довідник і дашборд відвідуваності. Для учнів і батьків».

Ролі: як не заблокувати одне одного на дві години

У команді з чотирьох найдорожча втрата — не помилка в коді, а троє, які сидять і чекають на четвертого

Заблокувати одне одного можна двома способами. Або двоє правлять той самий файл. Або одна робота не може початися, поки не готова інша.

Обидві біди лікуються заздалегідь, поки ви ще домовляєтеся. У процесі вони вже не лікуються — тільки перечікуються.

Ролей чотири, а команда буває з трьох або з п'яти. Тоді ролі об'єднують або ділять. Головне інше: біля кожної ролі має стояти ім'я. Роль без імені означає, що її не робить ніхто.

Порядок, який знімає очікування

1. Перші 20 хвилин — тімлід кладе на сервер порожній каркас: головну, team.css, п'ять порожніх тек. Решта в цей час готує свої файли локально, нічого не заливаючи.
2. Далі паралельно — кожен заливає свій блок у свою теку. Конфліктів немає: у різних теках різні файли.
3. Спільний шар чіпає тільки тімлід. Хочеш змінити team.css — кажеш уголос, тімлід міняє. Так не буває, що двоє залили різні версії одного файла по FTP і другий стер першого.
4. Тестувальник починає, коли є перший блок, а не коли готове все. Знахідка на 40-й хвилині коштує п'ять хвилин, на 110-й — уроку.

Де що лежить: структура репозиторію команди

Одна теча — публічна й видима всьому світу, друга — приватна. Плутанина між ними коштує модуля

Узгоджені імена: домовленість на п'ять рядків

Домовленість про імена виглядає дріб'язком. Рівно доти, доки хтось не назве файл Індекс копія (2).html.

Кирилиця й пробіли в іменах на сервері працюють. Але посилання на такий файл перетворюється на %D0%86%D0%BD%D0%B4%D0%B5%D0%BA%D1%81. Прочитати це неможливо, і помилка в такому посиланні шукається годинами.

• тільки малі латинські літери, цифри й дефіс: media-manifest.json;
• жодних пробілів, кирилиці, дужок і слів «копія», «final», «new»;
• головна сторінка теки — завжди index.html;
• тека — іменник у однині або множині, але однаково в усіх: не /book/ і /events/ вроздріб, а домовлено;
• сервер розрізняє регістр: Team.css і team.css — два різні файли, і на вашому ноутбуці під Windows це не видно.

README.md і SECURITY.md: два файли, які читають чужі

Один пояснює, як усе влаштовано. Другий каже, що робити людині, яка знайшла у вас дірку, — і саме він відрізняє серйозний проєкт від шкільного

README.md — не про ідею, а про пристрій

Найчастіша помилка — написати README як твір. «Ми вирішили зробити сайт, який допоможе учням». Такий текст не читає ніхто.

Цей файл відповідає на питання людини, яка вже на сайті. Її цікавить дві речі: де що лежить і до кого йти з питанням.

# Шкільний медіацентр — команда 3

Сайт про заходи школи: розклад, бот-довідник і дашборд відвідуваності.
Для учнів 5–11 класів і батьків. Адреса: http://91.219.61.4/s/team-3/

## З чого складається

| Блок      | Адреса     | Що робить                          | Звідки | Власник |
|-----------|------------|------------------------------------|--------|---------|
| Книга     | /book/     | історія школи, зроблена з AI       | тема 1 | Оля     |
| Дашборд   | /dash/     | 3 діаграми відвідуваності гуртків  | тема 3 | Максим  |
| AI-медіа  | /media/    | описи згенерованих ілюстрацій      | тема 4 | Даша    |
| Бот       | /bot/      | відповідає на питання про школу    | тема 7 | Тарас   |
| Події     | /events/   | журнал заявок із форми Google      | тема 6 | Ніна    |

## Як воно працює технічно

- сторінки статичні, спільна шапка й стилі — `/team.css`;
- усі форми шлють POST на `/api/form.php`; він перевіряє CSRF-токен,
  валідує поля, екранує вивід і дописує рядок у `~/data/form.jsonl`;
- бот звертається до `/api/chat.php`, ключ моделі лежить у `~/.env` (права 600);
- журнал подій наповнює `/api/hook.php` — приймає підписані події ззовні;
- дані живуть у `~/data/`, поза `~/www`, і по HTTP не віддаються.

## Чого тут навмисно немає

- відео й аудіо: правило модуля — медіа показуємо з екрана, на сервер не кладемо;
- персональних даних у дашборді: агреговані числа, без прізвищ.

## Як запустити локально

Відкрити index.html у браузері. Форми при цьому не працюють —
вони потребують PHP; перевіряйте їх на сервері.

Зверніть увагу на колонки «Звідки» і «Власник». Саме їх найчастіше забувають. І саме вони перетворюють текст на робочий документ: через місяць одразу видно, кого питати про блок і на якому уроці він з'явився.

SECURITY.md — і чому це не формальність

Уявіть: хтось випадково помітив, що ваша форма приймає чужі дані. Людина хоче попередити. Куди їй писати?

Якщо відповіді на сайті немає, буде одне з двох. Або вона промовчить, і дірка лишиться відкритою. Або напише публічно в чат класу — з деталями, які прочитають усі, зокрема й ті, кому не варто.

SECURITY.md закриває саме цей розрив. Це не файл «щоб було». Великі проєкти тримають такий роками, а стандарт RFC 9116 описує його машиночитаний варіант — /.well-known/security.txt.

# Як повідомити про вразливість

Дякуємо, що читаєте це. Якщо ви знайшли у нашому проєкті помилку,
що стосується безпеки, — напишіть нам, будь ласка, перш ніж розповідати
про неї публічно.

## Контакт

- пошта: team3-security@91.219.61.4
- або особисто: вчителю інформатики, кабінет 214

## Що написати

1. адресу сторінки або запиту;
2. що саме ви зробили (кроки, які можна повторити);
3. що отримали — код відповіді, шматок виводу, знімок екрана;
4. чим це небезпечно, на вашу думку.

## Що обіцяємо ми

- відповімо протягом 3 навчальних днів;
- скажемо, підтвердилася знахідка чи ні, і що виправили;
- подякуємо в цьому файлі, якщо ви не проти.

## Про що просимо вас

- не змінювати й не видаляти чужі дані;
- не влаштовувати навантаження на сервер;
- не публікувати деталі, доки ми не виправимо.

## Подяки

- (сюди потрапляють ті, хто нам допоміг)

Відповідальне розкриття — що це означає

Уяви, що ти помітив зламаний замок на сусідських дверях. Розумний порядок дій простий: спершу сказати сусідам, а не викласти фото дверей у чат будинку.

З дірками в сайтах домовилися так само. Той, хто знайшов, повідомляє приватно й дає час на виправлення. Той, чий сайт, не вдає, ніби нічого не було: виправляє і публічно дякує. Ця домовленість зветься відповідальним розкриттям.

Зобов'язання тут в обох сторін. У цьому вся суть: без другої половини перша перестає працювати.

CSRF: чужий сайт надсилає запит від твого імені

Головна нова тема уроку. Атака, у якій зловмисник не краде твій пароль і не бачить твоїх даних — він просто змушує твій браузер зробити те, чого ти не хотів

Уяви гардероб у театрі. Ти віддав куртку й отримав номерок. Далі гардеробник не питає твого прізвища: він дивиться на номерок і видає куртку тому, хто цей номерок приніс.

У вебі так само. Коли ти входиш на сайт, сервер віддає браузеру маленький рядок на кшталт sid=8f3a…. Це і є номерок, а зветься він cookie сеансу. Далі браузер сам, без твоєї участі, додає цю cookie до кожного запиту на цей сайт.

Ключове слово — кожного. Браузер не питає, чи ти цього запиту хотів. Він дивиться лише на адресу отримувача. Запит іде на 91.219.61.4/s/team-3? Отже, cookie цього сайту додається. А хто цей запит почав — твоя сторінка чи чужа — браузера довгий час не цікавило взагалі.

Чого CSRF не робить

Токен у формі: те, чого чужий сайт не може вгадати

Захист будується не на «звідки прийшов запит», а на «чи знає відправник секрет, який я показував тільки на своїй сторінці»

Логіка захисту коротка. Сервер віддає свою сторінку з формою і кладе в неї приховане поле з випадковим рядком. Той самий рядок він запам'ятовує в себе, у сеансі.

Коли приходить POST, сервер порівнює два рядки: той, що в полі, і той, що в сеансі. Збіглися — форма справді з нашої сторінки. Цей випадковий рядок і зветься токеном.

Чому це працює проти CSRF? Чужа сторінка може надіслати запит. Але прочитати вміст твоєї сторінки вона не може: браузер цього не дозволяє. Правило зветься політикою одного походження, same-origin policy. Тому й підставити правильний токен чужа сторінка не в змозі — вона його ніколи не бачила.

Як це виглядає в коді

<?php
declare(strict_types=1);

// cookie сеансу: тільки по HTTPS, недосяжна для JS, не їде на чужі сайти
session_set_cookie_params([
    'secure'   => true,     // лише по HTTPS
    'httponly' => true,     // JS не прочитає document.cookie
    'samesite' => 'Lax',    // другий рівень захисту, див. нижче
]);
session_start();

// токен народжується один раз на сеанс
if (empty($_SESSION['csrf'])) {
    $_SESSION['csrf'] = bin2hex(random_bytes(32));   // 64 шістнадцяткові символи
}
?>
<form method="post" action="/api/form.php">
  <input type="hidden" name="csrf"
         value="<?= htmlspecialchars($_SESSION['csrf'], ENT_QUOTES, 'UTF-8') ?>">

  <label for="name">Ім'я</label>
  <input id="name" name="name" maxlength="80" required>

  <label for="msg">Повідомлення</label>
  <textarea id="msg" name="msg" maxlength="1000" required></textarea>

  <button type="submit">Надіслати</button>
</form>

<?php
declare(strict_types=1);
session_start();

// hash_equals порівнює рядки за сталий час — щоб токен не можна було
// підібрати посимвольно, вимірюючи час відповіді сервера
$sent = (string)($_POST['csrf'] ?? '');
$real = (string)($_SESSION['csrf'] ?? '');

if ($real === '' || !hash_equals($real, $sent)) {
    http_response_code(403);
    header('Content-Type: text/plain; charset=utf-8');
    exit('403 · запит не з нашої сторінки');
}

// далі — решта фільтрів: валідація, honeypot, ліміт, екранування

Другий рівень: атрибут SameSite

Сервер може попросити браузер про послугу: «не надсилай цю cookie, якщо запит почався на іншому сайті». Прохання записують у самій cookie, в атрибуті SameSite. Значень у нього три.

Здається, що Lax робить токен зайвим. Не робить, і причин три.

Перша: Lax не рятує від запиту з піддомена того самого сайту — для браузера це той самий сайт. Друга: він не рятує, якщо дія змінює дані через звичайне GET-посилання. Третя: браузери поводяться по-різному. Chrome і Edge вважають cookie без атрибута такою, що має Lax. Інші браузери — не обов'язково.

Симулятор CSRF: три кроки й один вимикач

Пройди атаку так, як її бачить жертва. Потім увімкни токен і повтори ту саму атаку — крок за кроком, на тих самих даних

Значення cookie, час і текст записів — ілюстративні, вигадані для симулятора. Формати заголовків, коди відповідей і поведінка SameSite — справжні.

Шість фільтрів форми: конвеєр, який ви збирали весь модуль

Кожен фільтр ви вже десь бачили. Сьогодні вони вперше стають одним обробником, через який ідуть усі форми продукту

Чому саме ці шість, і що кожен не робить

Окремо про третій фільтр

У саду ставлять блюдце з солодкою водою: комахи злітаються туди й не лізуть у їжу на столі. Приманка робить свою роботу тим, що її помічають не всі.

У формі роль приманки грає зайве поле. Людина його не бачить: воно сховане стилями. Бот бачить усі поля підряд і заповнює їх усі. Прийшов запит із заповненим цим полем — писала машина, і зберігати такий запит не треба. Таке поле-приманку звуть honeypot, тобто «горщик з медом».

Обробник цілком

<?php
declare(strict_types=1);
session_start();
header('Content-Type: text/plain; charset=utf-8');

// ── ① розмір і метод ─────────────────────────────────────────
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);
    exit('405 · тільки POST');
}
if ((int)($_SERVER['CONTENT_LENGTH'] ?? 0) > 8192) {
    http_response_code(413);
    exit('413 · запит завеликий');
}

// ── ② CSRF-токен ─────────────────────────────────────────────
$real = (string)($_SESSION['csrf'] ?? '');
$sent = (string)($_POST['csrf'] ?? '');
if ($real === '' || !hash_equals($real, $sent)) {
    http_response_code(403);
    exit('403 · запит не з нашої сторінки');
}

// ── ③ honeypot: поле, приховане в CSS, людина його не бачить ─
if (trim((string)($_POST['website'] ?? '')) !== '') {
    http_response_code(200);          // боту кажемо «все гаразд»
    exit('Дякуємо!');                 // але нічого не зберігаємо
}

// ── ④ ліміт частоти: 10 надсилань за 60 секунд з однієї адреси ─
$ip   = (string)($_SERVER['REMOTE_ADDR'] ?? '0.0.0.0');
$slot = sys_get_temp_dir() . '/rl_' . hash('sha256', $ip) . '.txt';
$hits = array_values(array_filter(
    array_map('intval', file_exists($slot) ? file($slot) : []),
    static fn(int $t): bool => $t > time() - 60
));
if (count($hits) >= 10) {
    http_response_code(429);
    header('Retry-After: 60');
    exit('429 · забагато надсилань, спробуйте за хвилину');
}
$hits[] = time();
file_put_contents($slot, implode("\n", $hits) . "\n", LOCK_EX);

// ── ⑤ серверна валідація: клієнтської недостатньо ────────────
$name = trim((string)($_POST['name'] ?? ''));
$msg  = trim((string)($_POST['msg']  ?? ''));
$errors = [];
if (mb_strlen($name) < 2 || mb_strlen($name) > 80)    { $errors[] = 'name'; }
if (mb_strlen($msg)  < 5 || mb_strlen($msg)  > 1000)  { $errors[] = 'msg';  }
if ($errors !== []) {
    http_response_code(422);
    exit('422 · не пройшли поля: ' . implode(', ', $errors));
}

// ── зберігаємо СИРІ дані, поза www ───────────────────────────
$row = ['ts' => date('c'), 'name' => $name, 'msg' => $msg];
file_put_contents(
    getenv('HOME') . '/data/form.jsonl',
    json_encode($row, JSON_UNESCAPED_UNICODE) . "\n",
    FILE_APPEND | LOCK_EX
);

// ── ⑥ екранування — на ВИХОДІ, при показі ────────────────────
echo 'Дякуємо, ' . htmlspecialchars($name, ENT_QUOTES, 'UTF-8') . '!';

Форма по HTTP — помилка навіть у шкільному проєкті

Не тому, що «так прийнято», а тому, що по дорозі від класу до сервера є щонайменше троє, хто бачить трафік

Коли сторінка відкрита по http://, усе введене їде мережею відкритим текстом. Не «якось зашифроване за замовчуванням». Саме відкритим текстом, який читається як звичайний рядок.

Побачити його може будь-хто на шляху. Сусід у тій самій Wi-Fi-мережі. Адміністратор шкільного роутера. Провайдер.

Три речі, які HTTP ламає одночасно

1. Дані форми — ім'я, телефон, текст повідомлення читаються як звичайний рядок;
2. Cookie сеансу — її теж видно, а хто має cookie, той увійшов як ви. Тому й потрібен атрибут Secure: із ним браузер не надішле cookie по HTTP взагалі;
3. Сама сторінка — по HTTP її вміст можна не лише прочитати, а й підмінити дорогою: дописати скрипт, підмінити адресу в action форми. Форма виглядатиме вашою, а дані підуть кудись інде.

Що робимо у продукті

• усі внутрішні посилання — відносні від кореня (/api/form.php), а не з протоколом. Тоді сторінка по HTTPS сама тягне все по HTTPS;
• HTTP-версія сайту перенаправляє на HTTPS, а не показує копію;
• cookie сеансу — з атрибутами Secure, HttpOnly і SameSite=Lax;
• жодного <img>, <script> чи <link> з http:// — це «змішаний вміст», і браузер його заблокує мовчки.

Чек-лист готовності: 15 пунктів, 5 із них блокують здачу

Тестувальник команди проганяє цей список уголос. Кожен пункт має команду, якою його перевіряють, — не «здається, працює», а код відповіді на екрані

Позначайте пункт тоді, коли команда виконана й вивід збігся з очікуваним. Галочки зберігаються в браузері й переживають перезавантаження сторінки.

Окремо стоять пункти з позначкою блокує. Вони вирішують долю здачі. Скільки б відсотків не набралося, поки такий пункт червоний, продукт не приймуть.

Практика: зібрати, задокументувати, закрити форми

Кроки 1—4 робить уся команда разом, далі — паралельно за ролями. Галочки зберігаються

Автоперевірка

Чекер стукає у ваш продукт ззовні: перевіряє редирект на HTTPS, обходить сторінку й шле форми напряму. Спроби не обмежені

Демонстраційний режим: результат згенеровано для показу. На сервері ця кнопка викликає POST /api/check, який запускає /opt/lessons/15/check.sh від імені команди.

Що вчитель дивиться на екрані команди

• як команда наживо проходить усі п'ять компонентів з головної і назад — без правок адреси руками;
• AI-медіа з локальних тек учасників як частину демо: на сервері їх немає й бути не має;
• вихідний код сторінки з формою: чи справді там є приховане поле csrf і чи різне його значення у двох різних сеансах;
• README.md — і просить кожного учасника показати свій рядок у таблиці ролей та відкрити свій блок;
• SECURITY.md — і питає, що команда зробить, якщо про дірку напишуть за годину до захисту;
• підписані правила аудиту — без них команду не допускають до крос-аудиту на уроці 16.

Шкала виконання

Це те, що бачить учитель, коли виставляє оцінку.

Сім речень, які варто запам'ятати

• артефакт стає продуктом тоді, коли з будь-якої його сторінки видно всі інші, а чужа людина розуміє головну за десять секунд;
• браузер додає cookie до кожного запиту на домен — хто б той запит не почав;
• CSRF ламає не пароль, а припущення «якщо cookie є, то користувач цього хотів»;
• токен працює тому, що чужий сайт не може прочитати вашу сторінку, — а не тому, що він довгий;
• токен без hash_equals в обробнику — це не захист, а порожнє поле в HTML;
• шість фільтрів форми закривають шість різних дір і не замінюють одне одного;
• SECURITY.md — це не формальність, а єдиний спосіб зробити так, щоб про вашу дірку сказали вам, а не в загальний чат.

Де найчастіше помиляються

• токен генерується й малюється у формі, але в обробнику його ніхто не звіряє — форма «захищена» тільки на вигляд;
• токен перевіряється == замість hash_equals — працює, але дає підбирати його по часу відповіді;
• токен покладено в <input type="hidden"> і в GET-адресу «для зручності» — тепер він лежить у журналах сервера й у чужій історії браузера;
• при злитті компонентів права з'їхали: файли скопійовані з 777 — це блокуючий perms на уроці 16;
• README описує ідею, а не архітектуру: немає, який блок хто зробив і де він лежить;
• у SECURITY.md написано «пишіть нам» без жодного контакту;
• дані форми складено в ~/www/data/ — і весь журнал з іменами й телефонами віддається по HTTP усьому світу;
• honeypot зроблено як type="hidden" — бот його бачить і не заповнює, фільтр не ловить нічого.

Домашнє завдання

Підготуйте 3-хвилинне демо продукту за схемою «проблема → рішення → показ». Прорепетируйте його з секундоміром. Розподіліть репліки заздалегідь: хто говорить про проблему, хто веде показ, хто відповідає на питання про безпеку. Регламент на захисті жорсткий: 3 хвилини і 2 хвилини питань.

Другим пунктом кожен учасник записує одне речення про свій блок. Воно знадобиться, якщо на захисті спитають саме про нього. У реченні — що цей блок робить і який фільтр форми в ньому найважливіший.

Звідки взяті формулювання, коди й правила

Усе, що на цій сторінці можна перевірити самому, має посилання. Те, що вигадано для прикладу, підписано просто в тексті

• OWASP Cross-Site Request Forgery Prevention Cheat Sheet — першоджерело схеми «синхронізований токен»: як його генерувати, де зберігати й чому перевірка на сервері обов'язкова. cheatsheetseries.owasp.org · CSRF Prevention
• MDN, «Cross-site request forgery (CSRF)» — опис механізму трьома сторонами і те, чому cookie надсилається автоматично. developer.mozilla.org · CSRF
• MDN, атрибут SameSite — значення Strict, Lax, None, вимога Secure для None і різниця в поведінці браузерів за замовчуванням. developer.mozilla.org · Set-Cookie · SameSite
• RFC 6265bis, «Cookies: HTTP State Management Mechanism» — специфікація, у якій описано SameSite і рекомендацію трактувати відсутній атрибут як Lax. datatracker.ietf.org · rfc6265bis
• RFC 9110, «HTTP Semantics», розділ 15.5 — означення кодів, якими відповідає конвеєр фільтрів: 403 Forbidden, 413 Content Too Large, 422 Unprocessable Content. rfc-editor.org/rfc/rfc9110
• RFC 6585 — код 429 Too Many Requests і заголовок Retry-After для ліміту частоти. rfc-editor.org/rfc/rfc6585
• RFC 9116, «A File Format to Aid in Security Vulnerability Disclosure» — стандарт файлу /.well-known/security.txt, машиночитаного родича SECURITY.md. rfc-editor.org/rfc/rfc9116
• ISO/IEC 29147, «Vulnerability disclosure» — міжнародний стандарт процедури відповідального розкриття: що робить той, хто знайшов, і що зобов'язаний зробити той, кому повідомили. iso.org · ISO/IEC 29147
• GitHub Docs, «Adding a security policy to your repository» — звідки взято структуру SECURITY.md і те, чому файл кладуть у корінь проєкту. docs.github.com · SECURITY.md
• PHP: random_bytes() і bin2hex() — криптографічно стійке джерело випадковості; 32 байти дають рядок із 64 шістнадцяткових символів. php.net · random_bytes
• PHP: hash_equals() — порівняння за сталий час і пояснення, від чого воно захищає. php.net · hash_equals
• PHP: session_set_cookie_params() — параметри secure, httponly, samesite і вимога викликати функцію до session_start(). php.net · session_set_cookie_params
• PHP: htmlspecialchars() — прапорець ENT_QUOTES і чому кодування треба вказувати явно. php.net · htmlspecialchars
• MDN, Same-origin policy — правило, через яке чужа сторінка може надіслати запит, але не може прочитати відповідь і вміст вашої сторінки. Це фундамент, на якому тримається токен. developer.mozilla.org · Same-origin policy
• MDN, «Mixed content» — що саме браузер блокує на HTTPS-сторінці, якщо в ній лишилося посилання з http://. developer.mozilla.org · Mixed content
• RFC 6797, HSTS — заголовок Strict-Transport-Security, яким сервер забороняє браузеру взагалі ходити до нього по HTTP. rfc-editor.org/rfc/rfc6797
• curl, опція --write-out — змінні %{http_code} і %{redirect_url}, з яких складено команди чек-листа. curl.se · manpage · --write-out
• Приклади доменів — funny-cats.example і 91.219.61.4. Домен верхнього рівня .example зарезервовано саме для документації (RFC 2606), тому він нічий і нікуди не веде. rfc-editor.org/rfc/rfc2606
• Кодування й && у Windows PowerShell 5.1 — чому в командах чек-листа для Windows треба писати curl.exe, а не curl. learn.microsoft.com · Invoke-WebRequest

Повний список із поясненнями, що звідки взято і що є ілюстративним прикладом, — у файлі urok-15-джерела.md поруч із цією сторінкою.