# Безопасность

Версия источника: 4880e8b4372c96001c2e052be28b68a95d31252b
Синхронизировано: 2026-11-09T11:15:07.649Z
Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/4880e8b4372c96001c2e052be28b68a95d31252b

## Оглавление

- [Object-level authorization](#security-object-access)
- [Управление секретами](#security-secrets)
- [SQL-параметры](#security-sql-injection)
- [SSRF-защита](#security-ssrf)
- [Маскирование секретов в логах](#security-redaction)
- [Software supply chain](#security-supply-chain)
- [Лимиты ресурсов](#security-resource-limits)

<a id="security-object-access"></a>

# Object-level authorization

## Коротко

Вход в систему не даёт доступа ко всем записям.

## Плохо

```sql
SELECT * FROM orders WHERE order_id = $1
```

## Хорошо

```sql
SELECT * FROM orders
WHERE order_id = $1 AND tenant_id = $2
```

## Почему

Чужой идентификатор может быть известен или случайно раскрыт.

## Когда применять

tenant_id берётся из проверенного контекста, а не произвольного поля клиента. Для сложных ролей нужен явный механизм политик.

## Как проверить

- Пользователь одной организации не читает и не меняет данные другой?

## Человек

Определяет матрицу доступа к конкретным объектам.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- Пользователь одной организации не читает и не меняет данные другой?

## Источники

- [API1:2023 Broken Object Level Authorization - OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)

Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/object-access.md)

---

<a id="security-secrets"></a>

# Управление секретами

## Коротко

Используйте управляемую конфигурацию и ограниченный доступ вместо ключей в репозитории.

## Плохо

```text
Рабочий пароль записан прямо в README.
```

## Хорошо

```text
README содержит пример без значения.
Секрет передаётся через защищённую конфигурацию.
```

## Почему

Удаление файла из последнего коммита не убирает секрет из истории.

## Когда применять

При утечке сначала отзовите или замените ключ. Очистка истории — отдельная согласованная операция.

## Как проверить

- Проверьте исходники, историю, логи и сборку на реальные секреты.

## Человек

Выдаёт и отзывает доступы, назначает владельцев ротации.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- Проверьте исходники, историю, логи и сборку на реальные секреты.

## Источники

- [Secrets Management - OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)

Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/secrets.md)

---

<a id="security-sql-injection"></a>

# SQL-параметры

## Коротко

Не вставляйте пользовательскую строку непосредственно в SQL.

## Плохо

```python
cursor.execute("SELECT * FROM users WHERE name = '" + name + "'")
```

## Хорошо

```python
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))
```

## Почему

Пользовательский ввод не должен менять структуру команды.

## Когда применять

Пример для Python и Psycopg 3: `%s` — placeholder драйвера, а не строковая подстановка Python. Значения передаются отдельным аргументом. Для имён колонок и направления сортировки используйте разрешённый список; bind-параметры не заменяют SQL-идентификаторы.

## Как проверить

- Попробуйте кавычки и SQL-фрагмент во входном значении.

## Человек

Определяет доступные операции и минимальные права подключения к БД.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- Попробуйте кавычки и SQL-фрагмент во входном значении.

## Источники

- [SQL Injection Prevention - OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)
- [Passing parameters to SQL queries - psycopg 3.3.9.dev1 documentation](https://www.psycopg.org/psycopg3/docs/basic/params.html)

Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/sql-injection.md)

---

<a id="security-ssrf"></a>

# SSRF-защита

## Коротко

Проверяйте адрес назначения, перенаправления, DNS и объём ответа.

## Плохо

```text
Сервер скачивает любой URL из формы.
```

## Хорошо

```text
Разрешённые HTTPS-источники.
Запрет внутренних адресов и опасных редиректов.
```

## Почему

Пользователь может попытаться обратиться через ваш сервер к внутренним сервисам.

## Когда применять

Проверка строкового префикса недостаточна. Учитывайте IPv6, DNS rebinding и адрес после каждого перенаправления.

## Как проверить

- Проверьте loopback, частные адреса и редирект на них.

## Человек

Определяет разрешённые внешние адреса и сетевые границы.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- Проверьте loopback, частные адреса и редирект на них.

## Источники

- [Server Side Request Forgery Prevention - OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)

Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/ssrf.md)

---

<a id="security-redaction"></a>

# Маскирование секретов в логах

## Коротко

Записывайте идентификаторы операций и безопасные признаки вместо полного содержимого.

## Плохо

```text
log(request.headers, request.body)
```

## Хорошо

```text
log({request_id, route, status, duration_ms})
```

## Почему

Логи часто доступны большему числу систем, чем исходные данные.

## Когда применять

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

## Как проверить

- Нет ли Authorization, cookie, OAuth-кодов и платёжных данных в логах?

## Человек

Определяет чувствительные поля и требования к диагностике.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- Нет ли Authorization, cookie, OAuth-кодов и платёжных данных в логах?

## Источники

- [Logging - OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)

Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/redaction.md)

---

<a id="security-supply-chain"></a>

# Software supply chain

## Коротко

Фиксируйте воспроизводимый набор зависимостей и обновляйте его с проверками.

## Плохо

```text
Сборка каждый раз устанавливает произвольный latest.
```

## Хорошо

```text
Lockfile + зафиксированный runtime.
Обновления проходят проверку уязвимостей и тесты.
```

## Почему

Один исходный коммит должен позволять объяснить, что вошло в сборку.

## Когда применять

SBOM и provenance зависят от зрелости выпуска. Наличие файла не доказывает соответствие уровню SLSA.

## Как проверить

- В чистой среде устанавливаются те же зависимости?

## Человек

Выбирает доверенные источники и допустимый риск обновления.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- В чистой среде устанавливаются те же зависимости?

## Источники

- [SLSA • SLSA specification](https://slsa.dev/spec/v1.2/)

Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/supply-chain.md)

---

<a id="security-resource-limits"></a>

# Лимиты ресурсов

## Коротко

У запросов должны быть пределы размера, частоты и сложности.

## Плохо

```text
Неограниченный upload и тысячи попыток входа.
```

## Хорошо

```text
Лимит файла, квота пользователя, предел времени
и ограничение частоты чувствительных операций.
```

## Почему

Даже корректный запрос может исчерпать ресурсы сервиса.

## Когда применять

Лимиты выбираются под продукт и учитывают общие ресурсы; один IP не всегда равен одному пользователю.

## Как проверить

- Проверьте большой ввод, параллельные запросы и восстановление после лимита.

## Человек

Задаёт квоты, приоритеты и поведение при превышении.

## Агент

Реализует серверные ограничения и проверяет запрещённый запрос наряду с разрешённым.

Контроль результата:

- Проверьте большой ввод, параллельные запросы и восстановление после лимита.

## Источники

- [API4:2023 Unrestricted Resource Consumption - OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/)

Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09.

[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/security/no-secrets/rules/resource-limits.md)