Безопасность
Security capstone: модель угроз и харденинг веб-приложения
Читать про швы — не то же самое, что закрывать их в работающей системе. Возьми небольшое, но реалистичное веб-приложение — логин, сессии, account-API, сторонний вход, несколько зависимостей — смоделируй угрозы всего потока, затем захардени каждый слой трека и докажи каждый фикс конкретным before/after. Это аудит, который сеньор проводит перед запуском.
Преврати весь трек в один воспроизводимый инженерный цикл: смоделируй угрозы чувствительного запроса end-to-end, найди швы между правильными с виду контролями, захардени аутентификацию, авторизацию, работу с токенами, CSRF, хранение паролей, секреты и supply chain — и верифицируй каждый контроль доказательством, а не утверждением.
Возьми небольшое full-stack веб-приложение с логином, сессионной аутентификацией, per-user resource-API и хотя бы одним OAuth/OIDC-входом (своё, намеренно уязвимый стартер вроде OWASP Juice Shop или каркас ниже) и сделай модель угроз плюс захарденную сборку, которая композирует каждый контроль трека security — доказывая каждый фикс конкретной демонстрацией.
- Документ модели угроз сопоставляет каждый контроль с категорией OWASP и явно называет минимум три шва между правильными с виду слоями (например, AuthN-без-AuthZ, HttpOnly-без-CSRF-токена, стойкий-хеш-без-rate-limit).
- Демо (скрипт, тест или запись) показывает захарденное приложение: поддельный/неподписанный JWT отклонён, попытка IDOR отклонена, cross-site изменяющий состояние запрос заблокирован и брутфорс логина задросселирован — каждое с before (уязвимым) поведением рядом с after.
- git log / скан секретов по истории показывает, что в репо не осталось живых кредов, а ротация любого ранее закоммиченного секрета задокументирована.
- npm audit (или эквивалент) плюс закоммиченный lockfile и сгенерированный SBOM присутствуют; письменная заметка объясняет, как registry precedence защищает от dependency confusion.
- Одностраничный разбор называет для каждого слоя применённый контроль и шов, который он закрывает — оформленный как модель угроз, а не чек-лист.
- Добавь on-call security runbook: как триажить подозрение на кражу токена, репорт IDOR, алерт об утёкшем секрете и совет о вредоносной зависимости — с первым шагом сдерживания для каждого.
- Добавь refresh-token rotation с детекцией повторного использования и продемонстрируй, что повтор ротированного refresh-токена инвалидирует семейство сессии.
- Добавь SSRF-защиту любому серверному fetch (allowlist исходящих хостов, блокировка link-local/metadata диапазонов) и продемонстрируй заблокированный запрос к cloud-metadata эндпоинту.
- Встрой весь аудит в CI как гейты: задача SAST/scan зависимостей, сканер секретов и authz-набор тестов, который роняет сборку, если эндпоинт доступен без проверки владения.
Это аудит, который ты проводишь перед любым реальным запуском: смоделируй угрозы одного чувствительного запроса end-to-end, затем захардени каждый слой трека — закрепи алгоритм токена и валидируй iss/aud/exp, примени объектную deny-by-default авторизацию, скомпонуй HttpOnly + SameSite + CSRF-токен и убей XSS у источника, храни пароли в медленном солёном KDF за rate-лимитом, вытащи каждый секрет из репо и ротируй утёкшее, и закрой шаг установки от dependency confusion. Дисциплина везде одна: брешь живёт в шве между двумя правильными с виду контролями, поэтому ты композируешь их намеренно, применяешь least privilege для ограничения радиуса поражения и доказываешь каждый фикс доказательством, а не утверждением. Один раз сделав это на маленьком приложении, ты доводишь production-версию до мышечной памяти.