Доступ, ошибки ИИ и чек-лист

чем бэкенд отличается от остального кода

Что это

Завершение главы. Две темы: кто имеет право на что — и как проверить бэкенд-код.

Бэкенд отличается от всего остального в книге одним: здесь появляются чужие люди. Ошибка в скрипте стоит твоего вечера; ошибка в доступе на сервере может стоить чужих данных.

Доступ

Два разных вопроса, которые постоянно путают:

Типичная дыра выглядит так: токен проверяется, а право — нет.

@app.get("/subs/{user_id}")
def get_subs(user_id: int, current_user = Depends(get_current_user)):
    return SUBS[user_id]          # кто угодно читает чужие подписки

Пользователь вошёл честно, токен настоящий — и запрашивает /subs/999. Проверка личности прошла, проверки права нет.

    if current_user.id != user_id and not current_user.is_admin:
        raise HTTPException(status_code=403, detail="не ваши данные")

Что нельзя отдавать

• Токены и ключи — ни в код, ни в чат, ни в логи (статья 5.7).
• Дамп боевой базы — в нём чужие персональные данные. Для отладки делают обезличенную выборку.
• Трейсбек клиенту — он показывает структуру проекта (статья 7.2).
• Внутренние поля в ответе — хеши, служебные идентификаторы (статья 7.3).

Ошибки ИИ в бэкенде

1. Аутентификация без авторизации — разобрана выше.
2. 500 вместо 400 — нет валидации, сервер падает на кривых данных.
3. N+1 запрос — статья 7.6.
4. f-строка в SQL — инъекция, статья 7.5.
5. Нет транзакции там, где несколько изменений должны произойти вместе.
6. Нет response_model — в ответ уезжает всё.
7. Синхронный драйвер в асинхронном коде — sqlite3 вместо aiosqlite, блокирует весь сервер (статья 6.4).
8. Нет пагинации. GET /subs возвращает все записи. На тысяче всё ещё работает, на миллионе кладёт и сервер, и клиента.

Чек-лист бэкенд-кода

К общему чек-листу приёмки (статья 4.7) добавляются пять шагов.

1. Коды ответов

Проверить все четыре случая настоящими запросами:

curl -o /dev/null -w "%{http_code}\n" .../subs/7      # 200
curl -o /dev/null -w "%{http_code}\n" .../subs/999    # 404
curl -X POST ... -d '{"city":"X"}'  -w " %{http_code}\n"   # 422
curl -X POST ... -d '{"city":"Oslo"}' -w " %{http_code}\n" # 409 повторно

2. Чужие данные

Войти одним пользователем, запросить данные другого. Должен быть 403.

3. Запросы к базе

Сколько их на один HTTP-запрос? Больше двух-трёх — смотри на N+1.

4. Необратимое

Есть ли в диффе UPDATE, DELETE, DROP, миграции? Каждое — отдельно и внимательно (статьи 7.5, 7.7).

5. Что уезжает клиенту

Посмотреть реальный ответ целиком, а не схему. Нет ли лишних полей.

Как сказать ИИ

Проверь этот бэкенд-код по списку:
- есть ли проверка прав на конкретную запись, а не только токена
- какие коды отдаются на кривые данные и на отсутствие записи
- сколько запросов к базе на один HTTP-запрос
- есть ли f-строки в SQL
- что уезжает клиенту в ответе

Что из этого проблема? Если ничего — так и скажи.

Может ли пользователь 7 получить данные пользователя 8?
Покажи, каким запросом, или объясни, что мешает.

Шпаргалка