Приложение с заметками работает: можно войти, добавить запись и открыть её по ссылке. Нейросеть написала код, сборка проходит. Перед тем как приглашать пользователей, стоит проверить несколько ситуаций, которые не встречаются в демонстрации: чужой аккаунт, неверные данные, обрыв сети и повторное нажатие кнопки.

Путь одной операции от подтверждённой личности до проверенного результата и восстановления.

Возьмём учебный сервис заметок. Все проверки выполняем в своём тестовом окружении и на вымышленных данных. Результат каждого шага удобно записывать: действие, ожидаемое поведение, фактический ответ и исправление.

Может ли один пользователь открыть запись другого

Создайте двух пользователей, Анну и Бориса. Пусть у каждого будет одна заметка. Под учётной записью Бориса попробуйте открыть, изменить и архивировать запись Анны, подставив её идентификатор в запрос своего приложения.

Сам по себе вход в аккаунт не даёт доступа ко всем записям. В рекомендациях Open Worldwide Application Security Project по авторизации отдельно рассматривается проверка прав на каждый запрос. В нашем сервисе сервер должен находить заметку с учётом текущего пользователя.

Учебная ошибка выглядит так:

найти заметку по note_id
вернуть заметку

Проверка владельца меняет логику:

найти заметку по note_id и current_user.id
если запись недоступна: вернуть отказ
иначе выполнить разрешённое действие

Идентификатор пользователя берётся из проверенной сервером сессии. Полю user_id, присланному браузером, доверять нельзя. Закрепите сценарий тестом для чтения и изменения: запрет одного действия не доказывает запрет остальных.

Не попали ли ключи в браузер и репозиторий

Посмотрите, где приложение хранит ключ почтового сервиса, токен модели и пароль базы. Всё, что отправлено во фронтенд, потенциально доступно пользователю. Секреты серверных сервисов должны оставаться на сервере.

Проверьте также историю Git, журналы и сообщения об ошибках. Добавление файла в .gitignore не удаляет уже сохранённый ключ из истории. Если ключ был раскрыт, его нужно отозвать и заменить. Подробный жизненный цикл секретов разобран в руководстве авторов проекта по безопасности.

Для проверки достаточно списка имён переменных и мест хранения. Копировать значения ключей в новый чат с ИИ не требуется.

Проверяет ли сервер полученные данные

Отправьте пустой заголовок, очень длинный текст и строку вместо ожидаемого числа. Затем повторите запрос напрямую к API своего стенда, минуя форму. Ограничения в браузере помогают пользователю, но сервер должен проверять вход независимо.

Задайте понятный контракт: какие поля обязательны, каковы типы и допустимые размеры. Для текста «<script>пример</script>» проверьте, что приложение показывает его как текст. Проверка ввода и безопасный вывод решают разные задачи; запрет нескольких опасных слов не заменяет защиту. Это различие рассматривается в памятке по проверке входных данных.

Что случится, если ответ не придёт

Создайте заметку и отключите сеть в момент сохранения. Видит ли пользователь ошибку? Сохранился ли введённый текст? Может ли он повторить попытку? Если сервер успел записать данные, повторная отправка не должна незаметно создавать несколько одинаковых записей.

Там, где повтор вызывает внешний эффект, например отправляет письмо или списывает деньги, нужен отдельный механизм защиты от повторной операции. Успешный HTTP-ответ сам по себе не гарантирует правильность бизнес-действия.

Можно ли обновить приложение и восстановить данные

Запишите команды установки зависимостей, запуска и проверки. Убедитесь, что версии зависимостей фиксируются принятым в проекте способом. Попробуйте развернуть приложение в чистом тестовом окружении по собственной инструкции запуска.

Сделайте резервную копию тестовой базы и восстановите её отдельно. Только после восстановления можно утверждать, что этот путь проверен. Сохраните предыдущую рабочую версию приложения и порядок возврата к ней; изменения схемы данных могут требовать отдельного плана.

Как поручить проверку нейросети

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

Минимальный тест доступа, который можно выполнить

Условная функция ниже работает с вымышленными заметками в памяти. Она показывает проверку владельца после получения подтверждённой личности пользователя. В реальном сервере current_user_id должен приходить из проверенной сессии или токена, а не из произвольного поля запроса. Этот фрагмент не реализует вход и не заменяет защиту базы.

notes = {"n1": {"owner_id": "anna", "text": "Черновик"}}

def read_note(current_user_id, note_id):
    note = notes.get(note_id)
    if current_user_id is None:
        raise PermissionError("authentication required")
    if note is None or note["owner_id"] != current_user_id:
        raise LookupError("not found")
    return dict(note)

assert read_note("anna", "n1")["text"] == "Черновик"
try:
    read_note("boris", "n1")
except LookupError:
    pass
else:
    raise AssertionError("foreign note exposed")

Одинаковый внешний ответ для отсутствующей и чужой заметки в этом учебном сценарии уменьшает раскрытие информации. Но единый текст ошибки сам по себе не обеспечивает авторизацию. Существенно, что проверяется владелец, а операция не возвращает содержимое постороннему пользователю.

Отдельно выполните тот же тест для изменения и удаления. Частая ошибка: чтение защищено, а обновление ищет запись только по идентификатору. Ещё один случай: интерфейс скрывает кнопку, но прямой запрос всё равно принимается сервером. Проверять нужно фактическую операцию, а не видимость элемента.

Таблица приёмки одной функции

Для создания заметки запишите четыре сценария: корректный текст, пустое значение, слишком длинный текст и повтор запроса после потерянного ответа. У каждого сценария должен быть ожидаемый результат. Повтор не должен незаметно создавать две одинаковые записи, если пользователь намеревался создать одну.

Для редактирования добавьте конфликт двух вкладок. Первая сохранила новую редакцию, вторая отправляет старую. Система должна применить заранее выбранное правило: например, отклонить устаревшую ревизию и предложить перечитать данные. Молчаливое затирание чужой правки редко соответствует ожиданию пользователя.

Проверьте сохранность после перезапуска. Если заметки жили только в памяти процесса, успешное нажатие кнопки ещё не означает надёжное хранение. Если данные записываются на диск, проверьте чтение после нового запуска и восстановление из действительно созданной резервной копии в отдельном тестовом каталоге.

Самопроверка

Кнопка удаления чужой заметки скрыта. Достаточно ли этого? Нет: сервер должен отклонять прямую операцию.
Запрос создал запись, но ответ потерялся. Нужно ли слепо отправлять создание заново? Сначала используйте устойчивый идентификатор операции или сверку результата, иначе возможен дубль.
Сборка успешна. Проверена ли бизнес-логика? Нет. Сборка подтверждает только свою часть технических условий, а сценарии доступа и сохранности требуют отдельных проверок.

Частые вопросы

Нужно ли переписывать весь сгенерированный код вручную? Полезнее понять критические границы: данные, права, внешние действия и восстановление. Непонятный участок исследуйте небольшим проверяемым сценарием.

Можно ли дать ИИ тестировать свой же код? Можно использовать его помощь, но ожидаемое поведение и критерии должны опираться на задачу пользователя. Тест, повторяющий ошибочную реализацию, ошибку не обнаружит.

Когда приглашать первых пользователей? После проверки основных сценариев, понятных ограничений и рабочего способа восстановить данные. Не обещайте надёжность только по красивой демонстрации.

Просите объяснять найденную ошибку и показывать доказательство исправления. Разработчику всё равно нужно понимать, какие данные меняются и почему. Откройте Кодик, чтобы посмотреть доступные учебные направления и выбрать подходящий маршрут. Список выше помогает найти эти пробелы, но не заменяет полноценную проверку безопасности приложения.

Приложение написал ИИ: проверка прав, данных и повторных запросов перед запуском