Аудит permissions и auth-boundaries

Permission баги — самые опасные. UX-баг — раздражение, perf-баг — отток, permission-баг — data leak / unauthorised access / GDPR violation. Этот промт — структурированный pass через все auth-состояния × все защищённые ресурсы.

Site: {{site_url}} Auth model: {{auth_model}}

1. Auth-states которые нужно проверить

Для каждого: какие routes / actions / data доступны.

2. Resource × State matrix

Список всех защищённых resources (или actions):

RESOURCE: /admin/users (list all users)

State              | Expected | Actual | Issue
anonymous          | 401/redirect | 401 | ✓
unverified         | 401/redirect | 401 | ✓
logged-in (free)   | 403 | 200 (lists users!) | CRITICAL bug — data leak
logged-in (paid)   | 403 | 200 | CRITICAL
logged-in (admin)  | 200 | 200 | ✓
suspended          | 401 | 200 | CRITICAL
revoked            | 401 | 200 | CRITICAL
expired session    | 401 | 401 | ✓

Это матрица — заполни для каждого sensitive route / action.

3. Что проверять

3a. UI-level (что видит)

• Skрытые / показанные кнопки per role
• Меню items
• Settings panels
• Data в lists (видит ли users from другой organization)
• Buttons enabled / disabled — а если кликнуть на disabled через JS?

3b. API-level (что доступно)

• GET /api/items/{id} — может ли read someone else's item?
• POST /api/items — может ли create как другой user?
• DELETE /api/items/{id} — может ли удалить чужое?
• PATCH /api/items/{id} — может ли модифицировать чужое?

3c. Field-level (что в response)

• Endpoint возвращает item — содержит ли поля которые не должен (e.g., email других users, internal IDs)
• API response sanitised per role
• GraphQL queries: введён ли depth limit?

3d. Tenant isolation (для multi-tenant)

• User org-A не может видеть org-B данные
• Direct URL access (/orgs/X/items/Y) проверяется
• Search не возвращает cross-tenant results
• Webhooks / notifications scoped per tenant

4. Common holes

IDOR (Insecure Direct Object Reference)

/api/items/123  → user A's item
/api/items/124  → user B's item — accessible by A? NOT OK

Test: открой свой item, измени ID на чужой. Should be 403 / 404, not 200.

Privilege escalation

• Free user может upgrade сам через UI? Verify can't bypass payment
• User с role X может assign себе role Y? Verify через role-change API
• Self-elevation: free user попытка POST /api/users/me с {role: "admin"} — должен быть rejected

Token / session

• Token не expires когда должен
• Logout не invalidates all sessions (на других устройствах)
• Token reused после logout (server должен blacklist)
• CSRF tokens проверяются на mutating endpoints

Stale permissions

• User remove из team — может ещё открыть кэшированные URLs?
• Subscription cancel — paid features ещё доступны?
• 2FA disable одним user — others affected?

Privacy-adjacent (GDPR / CCPA)

• User can export свои данные (right to portability)
• User can delete account → реально удаляется data (или soft-delete с deadline)
• Removed user не появляется в logs / reports / shared content
• PII в URL parameters (e.g., email в query string) — leak risk

5. Testing методики

Manual

• Multiple browser sessions: incognito + regular + Firefox = 3 different users
• Switch between accounts на одной странице
• Use curl для direct API access с / без token
• Try common attack patterns: IDOR, parameter tampering

Automated

• OWASP ZAP — automated security scanner
• Burp Suite — manual + automated security testing
• Authentik / Auth0 SDK tests для auth flow
• Unit tests для permission check functions (RBAC)
• Integration tests for cross-tenant isolation

Pen-test

• Quarterly external pen-test для production-critical apps
• Bug bounty program (HackerOne) для ongoing coverage

6. Pre-flight checklist

Перед launch проверь:

• Все sensitive routes имеют middleware с auth-check
• Все DB queries фильтруют по user_id / org_id
• Логи не содержат plaintext passwords / tokens / PII
• Error messages не leak resource existence («User not found» vs «You don't have access»)
• Rate-limiting на auth endpoints (защита от brute force)
• Session cookies имеют HttpOnly, Secure, SameSite
• CORS configured минимально (не *)
• CSP enforced
• HSTS включён
• Subdomains scoped (cookie не leak'ает в evil.example.com)

7. Anti-patterns

• ❌ Hide UI элементов = «безопасно» — JS можно обойти, API доступен напрямую
• ❌ Frontend-only permission checks — must дублироваться на backend
• ❌ «User-id from JWT — доверяем» — token tampering возможен; verify signature
• ❌ Error message «User john@example.com not found» — leak existence; use «Invalid credentials»
• ❌ Tokens в URL (?token=...) — попадают в logs / referer; use header
• ❌ Same session token для всех devices — logout на одном не affect others
• ❌ Permission cache без invalidation — stale permissions persist
• ❌ Тестировать только happy path admin — все non-admin states пропустишь

8. Output

1. Resource × State matrix заполнена (это становится living document)
2. Critical findings — data leaks, privilege escalation paths
3. High-priority fixes в первой PR
4. Long-term hardening — RBAC framework, audit logs, rate limiting
5. Re-audit schedule — каждый release (если есть permission changes) + quarterly