Вопросы для собеседования специалиста по безопасности приложений

Что хотим услышать

• Суть: нет проверки прав на объект по идентификатору из запроса
• Поиск: два пользователя, подмена id во всех методах, включая экспорт и вложенные ресурсы
• Исправление: фильтр по владельцу или арендатору в запросе, централизованная проверка
• UUID не защита, ответ 404 для чужих объектов
• Регресс: автотесты на доступ в CI

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Жёсткая ссылка: ещё одно имя того же inode, равноправное с оригиналом
• Данные живут, пока счётчик ссылок больше нуля и файл никто не держит открытым
• Жёсткую нельзя на каталог и между разными ФС
• Символьная: отдельный файл, внутри которого путь к цели
• Символьная ломается при удалении или переносе цели, зато работает с каталогами и через ФС
• Пример: symlink на текущий релиз current -> releases/42 для атомарного переключения

Если ответил, копните глубже

Что хотим услышать

• textContent возвращает весь текст, включая скрытый, без учёта CSS
• innerText учитывает стили, возвращает видимый текст и при чтении вызывает пересчёт layout
• innerHTML читает и пишет разметку, присваивание парсит HTML
• Пользовательские данные через innerHTML вставлять нельзя: это XSS
• Перезапись innerHTML пересоздаёт потомков и теряет обработчики и состояние полей
• По умолчанию для текста выбирать textContent

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• Не хранить открыто и не шифровать: только односторонний хеш
• Медленный алгоритм: Argon2id, bcrypt, scrypt, а не SHA-256 и MD5
• Уникальная соль на пароль, параметры вместе с хешем
• Перец как дополнительный секрет вне базы
• Миграция старых хешей при входе, сравнение за постоянное время

Если ответил, копните глубже

Что хотим услышать

• GET читает и безопасен, POST меняет состояние
• GET идемпотентен, POST нет: его нельзя молча повторять
• GET кешируется браузером и прокси, POST по умолчанию нет
• Параметры GET в URL: попадают в логи и историю, длина ограничена серверами
• GET можно добавить в закладки и prefetch, поэтому нельзя менять данные по GET

Если ответил, копните глубже

Что хотим услышать

• Три дескриптора: 0 stdin, 1 stdout, 2 stderr
• > перезаписывает, >> дописывает, 2> для ошибок, < для ввода
• > file 2>&1 объединяет потоки, порядок важен: перенаправления слева направо
• Пайп передаёт только stdout, для ошибок нужен 2>&1 |
• sudo cmd > /etc/x не работает: файл открывает shell без прав, используют | sudo tee
• /dev/null для выбрасывания ненужного вывода

Если ответил, копните глубже

Что хотим услышать

• Три фазы: погружение, цель, всплытие
• Слушатели по умолчанию на всплытии, capture: true переносит на погружение
• target - где возникло, currentTarget - где висит обработчик
• stopPropagation останавливает путь по дереву, но не обработчики того же элемента
• preventDefault отменяет действие браузера и на распространение не влияет
• Не все события всплывают: focus, blur, mouseenter

Если ответил, копните глубже

Что хотим услышать

• Асинхронность: пользователь не ждёт долгой работы
• Сглаживание пиков: очередь копит, консьюмеры разбирают
• Развязка сервисов: продюсер не знает о получателях
• Ретраи при временных сбоях получателя
• Цена: eventual consistency, дубли, мониторинг отставания

Если ответил, копните глубже

Что хотим услышать

• Назвал реальную слабость, а не штамп
• Слабость не критична для роли
• Рассказал, что делает, чтобы её компенсировать
• Есть пример прогресса
• Коротко, без самобичевания

Если ответил, копните глубже

Что хотим услышать

• Оценка: инвентаризация сервисов, данных, текущих практик и инцидентов, приоритет по риску
• Быстрые победы: сканер секретов, SCA, базовые безопасные настройки шаблонов
• SAST с точными правилами и baseline, находки в PR
• Security champions и обучение, моделирование угроз для новых крупных фич
• Процесс: SLA по критичности, исключения, метрики
• Внешняя проверка: пентест критичных систем, политика раскрытия, затем баунти

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• INP складывается из задержки ввода, времени обработчиков и задержки отрисовки
• Задержку ввода создают длинные задачи, которые уже идут в момент клика
• Разбивать работу и уступать главный поток: scheduler.yield или setTimeout
• Сначала дать визуальный отклик, тяжёлое делать после
• Сокращать JS, гидрацию и ререндеры: код-сплиттинг, startTransition, мемоизация, виртуализация
• Мерить в поле с атрибуцией, чтобы знать конкретные медленные взаимодействия

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Сравнить риски: XSS крадёт токен из localStorage, cookie требует защиты от CSRF
• Рекомендация: сессия или refresh-токен в cookie HttpOnly Secure SameSite, короткий access в памяти
• CSRF-защита для cookie: SameSite, токен или проверка Origin
• Учесть поддомены: SameSite считает их одним сайтом
• CORS: точный allowlist origin, credentials только где нужно
• В любом случае строгая защита от XSS и CSP

Если ответил, копните глубже

Что хотим услышать

• Измерить: Navigation Timing и RUM по этапам (DNS, connect, TLS, TTFB, загрузка, рендер), Lighthouse и WebPageTest
• Сеть: CDN ближе к пользователю, HTTP/2 или HTTP/3, preconnect к сторонним доменам
• Сервер: медленный TTFB → кеширование, отдача статики с CDN, 103 Early Hints
• Ресурсы: Brotli, меньше JS, code splitting, оптимизированные картинки с размерами
• Рендер: критический CSS, defer для скриптов, без блокирующих сторонних скриптов

Если ответил, копните глубже

Что хотим услышать

• Сначала SIGTERM, затем ожидание (таймаут), и только потом SIGKILL
• Приложение ловит SIGTERM: перестаёт принимать новые запросы, дожидается текущих, закрывает соединения с БД
• SIGKILL нельзя перехватить, поэтому после него остаются lock-файлы и незавершённые операции
• systemd делает так же: KillSignal, TimeoutStopSec, затем SIGKILL
• В контейнере процесс должен быть PID 1 или запускаться через init (tini), иначе сигнал не дойдёт
• Код выхода 143 после SIGTERM и 137 после SIGKILL помогают понять, как завершился процесс

Если ответил, копните глубже

Что хотим услышать

• Экранирование по умолчанию: фреймворк с автоэкранированием, запрет innerHTML в линтере
• Пользовательский HTML только через санитайзер (DOMPurify)
• Проверка протокола у пользовательских URL в href и src
• Строгая CSP с nonce и strict-dynamic, сначала в Report-Only
• Trusted Types, чтобы все вставки HTML шли через одну политику
• HttpOnly-куки для сессии, SRI для сторонних скриптов

Если ответил, копните глубже

Что хотим услышать

• Требования: публикация поста, подписка, лента с пагинацией; порядок по времени (ранжирование вне рамок или упрощённо); лента грузится < 200 мс, допустима задержка появления поста в секунды
• Оценка нагрузки: 100 млн DAU, 10 открытий ленты в день ≈ 10 000 RPS чтения, в пике ~30 000; 10 млн постов в сутки ≈ 100 RPS записи; при 200 подписчиках в среднем ≈ 20 000 вставок в ленты в секунду
• API: POST /posts; GET /feed?cursor=...&limit=20; POST /users/{id}/follow
• Данные: посты в шардированной БД по author_id, граф подписок отдельно, готовые ленты как списки id постов в Redis (последние ~500), медиа в S3
• Компоненты: сервис постов, очередь событий публикации, fan-out воркеры, сервис ленты, кеш постов, CDN для медиа
• Узкие места: аккаунты-звёзды (гибрид on write + on read), неактивные пользователи (не раскладывать, собирать при входе), пагинация курсором, память Redis, удаление и редактирование постов

Если ответил, копните глубже

Что хотим услышать

• Акцент на масштаб и влияние, а не на список фич
• Метрики бизнес-эффекта
• Лидерство: менторинг, процессы, архитектурные решения
• Компактность: старый опыт свёрнут
• Понимание, что резюме под роль, а не под всё сразу

Если ответил, копните глубже