Authorization

Критично: admin panel — це концентрат ризику.; !; * Frontend authorization покращує UX, але не є собою security boundary.; !; Практична роль: authorization існує не тільки в web apps, а й на рівні операційної системи.; GET /api/projects/123

- users.manage

Чи є собою process для відкликання доступу?;

}

Проста аналогія: RBAC — це як бейдж у компанії: посада або роль визначає, куди можна заходити.;

Access Control

Authorization у Kubernetes

переважні аспекти хорошої авторизації

}

Приклад:

Чи відділена authentication від authorization?; Приховати кнопку на frontend недостатньо.;

* погані role checks;
* IDOR;
* mass assignment;
* insecure admin endpoints;
* неправильні JWT claims;
* слабкі policies;
* надмірні default permissions;
* відсутність audit.; !; }

canDoStuff
'''Критично:''' cloud role з `*:*` має змогу бути зручна на старті, але дуже небезпечна в production.; '''Головна перевага:''' авторизація надає можливість системі бути відкритою для багатьох користувачів, але не відкритою для всього.; | користувач системи має змогу редагувати тільки свої документи
|}

Погано:

Чи увімкнена функція?;<syntaxhighlight lang="typescript">
== Role ==

</div>

'''Практична роль:''' service layer бачить і користувача, і ресурс, з цієї причини має змогу ухвалити точніше authorization-рішення.; У cloud platforms authorization часто реалізується через IAM.; CI service account має змогу deploy-ити application, але не має змогу читати billing або видаляти production database.; Код
- article.publish
Якщо користувач системи не має доступу до invoice `1002`, backend має повернути заборону, навіть якщо ID існує.; Чи перевіряється ownership?;

Файлові системи теж мають authorization.; Одна з найпоширеніших помилок у безпеці застосунків — думати, що якщо користувач системи увійшов у систему, то він уже “безпечний”.; * Хороша authorization-модель часто непомітна користувачу, але дуже помітна команді підтримки й безпеки.; Role: Editor

- content.read

Middleware корисний для: !; - Admin

- Viewer
SaaS authorization має враховувати:

У multi-tenant systems одна платформа обслуговує багато організацій або клієнтів.; '''Permission''' — конкретний дозвіл на дію.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

<syntaxhighlight lang="text">

Owner:

І повертати:

* хто має змогу отримати доступ;
* до чого саме;
* які дії дозволені;
* за яких умов;
* хто надав доступ;
* як доступ відкликати;
* як перевірити історію доступів.; * плутати login з доступом;
* перевіряти права тільки на frontend;
* приховувати кнопку, але не захищати API;
* давати всім admin;
* не перевіряти ownership;
* не перевіряти tenant_id;
* довіряти role з client payload;
* робити hardcoded checks у різних місцях;
* не тестувати заборонені сценарії;
* не логувати admin actions;
* не відрізняти 401 і 403;
* використовувати wildcard permissions без потреби;
* не перевіряти JWT signature;
* зберігати занадто довгі access tokens;
* не відкликати доступ після зміни ролі.;== Authorization і Subscription Plans ==

* system admin;
* organization owner;
* workspace admin;
* project manager;
* member;
* guest;
* billing admin;
* read-only auditor.; Небезпечною є собою не простота, а відсутність перевірок.;

JWT Claims

дозволені дії;
заборонені дії;
доступ до чужих ресурсів;
tenant isolation;
role boundaries;
field-level permissions;
admin-only endpoints;
expired tokens;
missing scopes;
changed permissions;
deleted users;
edge cases.; Це платформа правил, яка захищає кожну важливу дію й кожен важливий ресурс.; {| class="wikitable"

Практична роль: authorization має змогу перевіряти не тільки роль, а й те, чи оплачена функція в поточному plan.; істотно: якщо запит прийшов “із внутрішньої мережі”, це ще не означає, що йому можна довіряти без перевірки.;

Приклад verbs:

* повторного використання checks;
* зменшення дублювання;
* централізації базових правил;
* простих role checks;
* API protection.; "role": "editor",

Практична роль: deny by default робить систему безпечнішою при помилках конфігурації.; * 403 означає, що користувач системи має змогу бути відомим системі, але дія йому заборонена.;== Service-to-Service Authorization ==

мінімальними;
регулярно перевіреними;
прив’язаними до ролей;
audit-friendly;
без wildcard permissions без потреби;
розділеними між environments.; Поганий UX:

Admin має змогу запросити member.; Приклади ролей: !; | користувач системи увійшов через email і пароль |- | Authorization | Що тобі дозволено?; * 2FA;

least privilege;
audit logs;
approval flows;
session expiration;
IP allowlist у частині сценаріїв;
separate admin roles;
break-glass access;
monitoring.;</syntaxhighlight>

Приклад:

</syntaxhighlight>

пояснює, чому дія недоступна;
не показує зайві admin controls;
показує правильні empty states;
пропонує попросити доступ;
не розкриває зайві details;
відрізняє “немає доступу” від “ресурс не існує” там, де це безпечно.;

Якщо backend без перевірки записує всі поля в database, користувач системи має змогу сам собі підняти роль.; Підхід

Least privilege — принцип мінімально необхідних прав.; Суть:

function canViewInvoice(user: User, invoice: Invoice): boolean { Авторизація має змогу базуватися на ролях, permissions, attributes, ownership, policies, scopes, groups, organization membership, subscription plan, security level або context.; Приклад payload:

- content.create

Authorization і Feature Flags

Authorization у SaaS

Authorization у файлових системах

Policy

Authorization має змогу перевіряти:

Чи є собою negative tests?; * Практики authentication і authorization у web applications.;<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
Поширені помилки:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Краще:
IDOR часто виникає через:

|- | Centralized | Єдине місце правил, простіший audit | має змогу стати bottleneck або single point of failure |- | Decentralized | Сервіси автономні, менше latency | Ризик різних правил у різних місцях |}

У web/API часто використовують статуси:

спільні policies;
local enforcement;
centralized identity;
audit;
shared libraries;
gateway checks.; Billing admins can update payment methods.; Практична роль: authorization без audit logs відповідає “можна чи ні”, але не завжди сприяє потім зрозуміти, хто що зробив.; Цей приклад показує два варіанти доступу:

Чи зрозуміла permission model команді?; allow

Access token має бути:

Cloud infrastructure

* `read:profile`;
* `write:profile`;
* `read:email`;
* `repo`;
* `payments:read`;
* `payments:write`;
* `calendar.events.read`;
* `calendar.events.write`.; '''Практична роль:''' permission — це маленький атом доступу, з якого будують ролі й policies.; '''Практична роль:''' CMS authorization надає можливість редактору писати статті, але не обов’язково змінювати системні конфігурація.; Поняття
'''Найлюдяніший факт:''' authentication — це показати паспорт на вході, а authorization — це перевірити, чи маєш ти ключ саме від цієї кімнати.;<syntaxhighlight lang="text">
Viewer не має змогу створити project.; Чи логуються admin actions?; '''Privilege escalation''' — ситуація, коли користувач системи отримує більше прав, ніж мав.; Document 123:
== Приклади сценаріїв використання ==
'''Практична роль:''' така модель проста для пояснення й достатня для багатьох командних застосунків.; Чи всі protected endpoints перевіряють access?; це бізнес-процес перевірки, що користувач системи, сервіс або платформа має право виконати певну дію або отримати доступ до певного ресурсу виступає ключовою рисою '''Authorization''' або '''авторизація'''.;

'''Практична роль:''' authorization — це практична реалізація access control у застосунку або системі.;<syntaxhighlight lang="typescript">
</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Audit logs важливі для:

користувач системи бачить тільки rows, де tenant_id = його tenant_id.; Дозволи
- Owner

Ownership часто застосовується для:

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Він має змогу отримувати:

Див.; додатково

SaaS workspace

!; * read;

create;
update;
delete;
approve;
export;
invite;
publish;
deploy;
refund;
manage users.; У microservices authorization має змогу бути складнішою, бо рішення для бізнесу розподілені між сервісами.;

Приклад правила: Головна думка: authorization — це не одна перевірка “чи користувач системи увійшов”.; RBAC добре підходить для:

чи користувач системи authenticated;
чи має permission на action;
чи має доступ до конкретного resource;
чи належить resource до його tenant або organization;
чи не перевищено scope token;
чи надає можливість subscription plan цю дію.;=== Інтернет-магазин ===

Типові рівні: Кожен endpoint має перевіряти:

Добрий UX: !; Row-Level Security або RLS — механізм, який обмежує доступ до рядків у таблиці.;</syntaxhighlight>

Authorization: Alice має змогу редагувати проєкт A, але не має змогу видалити проєкт B.;

користувачу;
ресурсу;
дії;
організації;
середовищу;
часу;
location;
device;
security level;
subscription plan.; Приклади scopes:

Authorization Testing

- project.create Для admin-доступу корисні:

Приклад ownership check

centralized authorization service;
local policy enforcement;
API gateway authorization;
service mesh policies;
token scopes;
shared policy library;
policy-as-code.; Приклад:

Admin Authorization

захист даних;
контроль доступу;
менший ризик витоків;
відповідність compliance;
безпечна командна робота;
супровід ролей;
зрозуміші межі відповідальності;
менша шкода при компрометації акаунта;
auditability;
кращий UX для різних типів користувачів;
можливість enterprise-функцій;
супровід multi-tenant SaaS.;== Джерела ==

if (!canUpdateProject(user, project)) {

Permission краще формулювати конкретно, а не занадто загально.; !;== Коли authorization можна спростити == </syntaxhighlight> </syntaxhighlight>

Authorization і UX

ABAC

!; Проста різниця: 401 — “спочатку увійди”, 403 — “ти увійшов, але це тобі не дозволено”.; Policy engine — компонент, який приймає рішення для бізнесу про доступ.; Приклад небезпечної помилки:

API;
admin panels;
cloud IAM;
internal tools;
database permissions;
file access;
enterprise systems.; ServiceAccount із зайвими правами має змогу стати шляхом до компрометації кластера.; Практична роль: ACL надає можливість керувати доступом до конкретного об’єкта, а не лише через глобальні ролі.;

Краще:

Це означає:

явно дозволяти тільки permitted fields;
окремо перевіряти role changes;
не довіряти client payload;
використовувати DTO або schema validation.; Насправді login лише підтверджує особу.; На практиці часто використовують змішаний підхід:

хто виконав дію;
яку дію;
над яким resource;
коли;
з якої IP або device;
чи була дія дозволена;
що змінилося;
request id;
admin context;
reason або ticket у enterprise-сценаріях.; Небезпека: authorization-помилка має змогу бути тихою: платформа не падає, але показує інформаційні дані не тій людині.; "sub": "user_123",

користувач системи має змогу редагувати profile, якщо profile.user_id == current_user.id.; Практична роль: у microservices істотно вирішити, де саме ухвалюється authorization decision і де воно enforced.; - content.update

vertical privilege escalation — звичайний користувач системи отримує admin-права;
horizontal privilege escalation — користувач системи отримує доступ до даних іншого користувача такого ж рівня.; * Документація щодо secure API design, policy engines, zero trust і security testing.; Ризики:

- users.manage

Приклад:

email;
phone number;
address;
payment data;
medical data;
documents;
messages;
location;
logs із персональними даними;
exports;
backups.;

compute;
storage;
databases;
secrets;
logs;
networks;
Kubernetes;
serverless functions;
billing;
monitoring;

deployment pipelines.;

'''Практична роль:''' observability сприяє побачити не тільки помилки авторизації, а й спроби зловживання доступом.; async function updateProject(user: User, projectId: string, input: UpdateProjectInput) {

== Ownership ==
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Backend має перевіряти:

multi-tenant SaaS;
finance systems;
healthcare;
internal analytics;
security-sensitive data;
shared databases.;

traditional web apps;
admin panels;
CMS;
internal tools;
server-rendered applications.;

current user;
action;
target resource;
ownership;
role;
permissions;
tenant;
scopes;
policy;

business rules.;

У microservices або distributed systems сервіси додатково мають авторизуватися між собою.; Приклад:

== Приклад простої RBAC-моделі ==

IAM має змогу керувати доступом до:
'''істотно:''' JWT потрібно перевіряти: signature, expiration, issuer, audience і claims.;=== CMS ===

'''істотно:''' frontend-перевірки потрібні для зручності, але справжня безпека має бути на backend.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

* Authorization починається після authentication, а не замість неї.; * Матеріали з application security щодо access control.;</div>
</div>
invoice.refund

<syntaxhighlight lang="text">
Приклад:
Authorization напряму пов’язана з privacy, бо визначає, хто має змогу бачити персональні інформаційні дані.; * видалення користувачів;
* зміна ролей;
* refunds;
* перегляд приватних даних;
* export data;
* system settings;
* impersonation;
* moderation;
* billing;
* security logs.;== API Authorization ==

'''істотно:''' у SaaS недостатньо ролі “admin”.; Приклад:
- article.update
Приклад тесту:

 throw new Error("Forbidden");

* файлів;
* документів;
* shared folders;
* collaboration tools;
* object storage;
* granular sharing;
* ресурсів, де доступ налаштовується окремо.; Якщо він витік, його потрібно вважати скомпрометованим.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

app.delete('/projects/:id', requirePermission('project.delete'), deleteProject);

"tenant_id": "org_456"

Frontend authorization зазвичай відповідає за UX: Типові permissions:

Але frontend authorization не є собою достатнім захистом.;

</div>
Authorization потрібно тестувати так само серйозно, як бізнес-логіку.;== Session-Based Authorization ==
RLS корисна для:
Небезпечний приклад:

</div>

Приклади claims:

Приклади permissions:

* subject;
* action;
* resource;
* context;
* attributes;
* policies.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

</div>

== Privilege Escalation ==

* session user id;
* roles;
* permissions;
* organization membership;
* CSRF protection;
* session expiration;
* device/session state.;</div>

Приклад SQL-ідеї:
Основні переважні аспекти:
== OAuth Scopes ==

'''Mass assignment''' — проблема, коли користувач системи має змогу передати зайві поля й змінити те, що не мав права змінювати.;== Frontend Authorization ==

* get;
* list;
* watch;
* create;
* update;
* patch;
* delete.; Недоліки

Тести мають перевіряти:

</div>
== Access Token ==
User A не має змогу переглянути invoice User B.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Приклади:

'''Практична роль:''' хороша авторизація має бути не тільки безпечною, а й зрозумілою для користувача.;<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

* repeated denied requests;
* access to sensitive resources;
* admin role changes;
* failed policy checks;
* unusual exports;
* cross-tenant access attempts;
* sudden permission changes;
* token misuse;
* service account anomalies.; * Документація щодо RBAC, ABAC, ACL, OAuth scopes, JWT claims і API security.; якщо department користувача збігається з department документа

відсутність ownership check;
перевірку лише login;
predictable IDs;
слабку tenant isolation;
authorization тільки на frontend;
reuse endpoints без policy.; Потрібні негативні тести: “користувач системи не повинен мати доступ”.;</syntaxhighlight>

Коли потрібна складна authorization-модель

Простіша модель доречна, якщо:

Owner має змогу керувати billing і users, Admin має змогу запрошувати учасників, Editor має змогу редагувати контент, Viewer має змогу тільки переглядати.; ABAC гнучкіший за RBAC, але складніший.; У Kubernetes авторизація часто функціонує через RBAC.;== ACL ==

Access control відповідає на питання:
== Authorization і Privacy ==
== Тематичні мітки ==
|-
| 401 Unauthorized
| користувач системи не authenticated
| Немає token або session недійсна
|-
| 403 Forbidden
| користувач системи authenticated, але не має прав
| Немає permission на дію
|}

Unix-приклад:

'''Policy''' — правило або набір правил авторизації.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Погано:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Бази даних додатково мають власну систему прав.; '''Критично:''' privacy-порушення часто починаються не з хакера, а з того, що занадто багато внутрішніх користувачів мають зайвий доступ.;== Authorization Middleware ==
</div>
== Authorization у Microservices ==

'''Deny by default''' — правило, за яким доступ заборонено, якщо немає явного дозволу.; * RBAC простіший для пояснення людям, а ABAC гнучкіший для складних правил.; '''істотно:''' роль має відповідати реальній відповідальності людини, а не бути випадковим набором прав.;</div>
Приклад:
'''Практична роль:''' policy перетворює бізнес-правило доступу на перевірне технічне правило.;<syntaxhighlight lang="text">
Attributes можуть належати:
Чи не зберігаються зайві permissions у token?; * users;
* roles;
* grants;
* schemas;
* table permissions;
* row-level security;
* column permissions;
* views;
* stored procedure permissions.; У SaaS доступ має змогу залежати від тарифу.; '''Критично:''' API не має покладатися на те, що frontend “не покаже кнопку”.; * service identity;
* allowed actions;
* mTLS;
* service tokens;
* scopes;
* network policies;
* workload identity;
* API gateway policies;
* zero trust principles.; У session-based applications користувач системи входить у систему, а сервер зберігає session.; ACL добре підходить для:
'''ABAC''' або '''Attribute-Based Access Control''' — модель, де доступ залежить від attributes.; POST /api/projects/123/invite
Editor:
Добрі практики:
== Least Privilege ==
Audit log має змогу містити:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Admin authorization має бути особливо обережною.;== Цікаві факти про Authorization ==
Feature flag відповідає:

'''Критично:''' privilege escalation часто небезпечніша за звичайний bug, бо відкриває доступ до чужих або адміністративних дій.; Якщо немає правила — дозволити.;== Загальний характеристика ==
- project.create
<syntaxhighlight lang="text">

Чи є собою least privilege?; * security;
* compliance;
* incident response;
* debugging;
* accountability;
* forensic analysis.; adminPower

 "name": "Oleh",

* сторінок;
* API endpoints;
* файлів;
* документів;
* баз даних;
* адміністративних функцій;
* billing;
* reports;
* user profiles;
* організацій;
* команд;
* проєктів;
* записів;
* налаштувань;
* internal tools;
* cloud resources;
* microservices.; Значення

* витоку даних;
* IDOR;
* privilege escalation;
* доступу до чужих акаунтів;
* незаконних змін;
* несанкціонованого export;
* фінансових втрат;
* порушення privacy;
* втрати довіри;
* compliance-проблем;
* компрометації admin panel;
* зламу multi-tenant isolation.; Scopes допомагають third-party applications отримувати не весь доступ, а тільки потрібний набір прав.; Service layer часто є собою хорошим місцем для resource-specific authorization.;== Authorization у Service Layer ==
Database authorization має змогу включати:
- project.read
Приклади дій:
IAM policies мають бути:
Admin actions можуть включати:

'''Authentication''' і '''authorization''' часто плутають, але це різні речі.;</div>

* короткоживучим;
* захищеним;
* переданим через HTTPS;
* перевіреним на backend;
* обмеженим потрібними scopes;
* відкликаним або заміненим при ризику.; Зловмисник має змогу викликати endpoint напряму.; * Зміна ролі користувача — це security-sensitive action.; '''Найлюдяніший факт:''' хороша авторизація — це як добре організована будівля: люди без зайвих зусиль потрапляють туди, куди їм треба, але не блукають у чужих кабінетах.; '''Authorization middleware''' — проміжний шар, який перевіряє доступ перед виконанням endpoint.;<syntaxhighlight lang="text">

які потрібні для його задачі.; Authorization і caching потрібно поєднувати обережно.; Backend authorization — головне місце перевірки доступу.;<syntaxhighlight lang="text">
- organization.manage
'''Практична роль:''' backend authorization — це дверний замок, а frontend authorization — табличка на дверях.; * IDOR часто виглядає як звичайний endpoint із параметром ID.;== Database Authorization ==

'''істотно:''' навіть якщо ID invoice передано в URL, backend має перевірити, чи має користувач системи доступ до цього invoice.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>

SaaS-застосунки часто мають складну модель доступу.; Viewer: Критично: у multi-tenant системі кожен запит до resource має перевіряти tenant boundary.; істотно: application authorization і database authorization можуть доповнювати одна одну, але не треба давати застосунку database superuser без потреби.; * `sub`;

`iss`;
`aud`;
`exp`;
`iat`;
`role`;
`scope`;
`tenant_id`;
`permissions`.; * Audit logs часто стають єдиним способом зрозуміти, хто отримав доступ і що зробив.; {| class="wikitable"

JWT claims — твердження всередині JSON Web Token, які можуть містити інформацію про користувача або права.; істотно: головне — не де лежать правила, а чи вони послідовні, перевірені й зрозумілі.;

IDOR

Authorization застосовується для контролю доступу до:

Хороша authorization-модель використовує least privilege, deny by default, backend checks, resource-level validation, tenant isolation, audit logs і тести заборонених сценаріїв.;

</syntaxhighlight>

Authentication: Alice успішно увійшла в систему.; /invoices/1002

Цікавий факт

Основна ідея: authorization — це не вхід у систему, а перевірка прав після входу: чи має змогу саме цей користувач системи зробити саме цю дію з саме цим ресурсом.; Чи перевіряються JWT signature, exp, iss і aud?; Потрібно обмежувати доступ до:

Хороші практики Authorization

Підходи:

fullAccess
</div>
}

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

'''Критично:''' access token — це ключ доступу.; '''істотно:''' centralized policy engine сприяє узгодити правила, але створює залежність, яку потрібно добре тестувати й моніторити.; Покупець має змогу бачити свої замовлення, support agent має змогу переглядати звернення, finance manager має змогу робити refunds, але не змінювати код товарів.; - project.update

 throw new NotFoundError();

* Free plan — 1 project;
* Pro plan — unlimited projects;
* Enterprise plan — audit logs і SSO;
* Basic plan — no export;
* Team plan — role management.; * Least privilege — один із найважливіших принципів безпеки.; * кешування private response як public;
* показ чужих даних через shared cache;
* stale permissions;
* роль змінилася, а cache ще надає можливість доступ;
* CDN віддає персональні інформаційні дані;
* browser cache зберігає sensitive page.; '''Небезпека:''' найтиповіша помилка — перевірити “користувач системи увійшов” і забути перевірити “цей ресурс справді його”.; '''OAuth scopes''' — обмеження прав access token у OAuth-сценаріях.; * user profiles;
* personal documents;
* orders;
* comments;
* messages;
* uploaded files;
* private notes;
* individual settings.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* перевірку ownership;
* backend authorization;
* least privilege;
* tests;
* audit для важливих дій.; Project members can view project tasks.; * дублювання правил;
* inconsistent policies;
* stale permissions;
* latency;
* distributed tracing;
* audit complexity;
* token propagation;
* confused deputy problem.;</div>

Authorization-події потрібно спостерігати.;<syntaxhighlight lang="typescript">
Billing service має змогу читати user profile,
== Приклад checklist для Authorization ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''істотно:''' authorization — це не тільки “чи можна endpoint”, а й “які поля можна змінювати”.; Погана авторизація має змогу призвести до IDOR, privilege escalation, витоку даних і небезпечного доступу до admin-функцій.;

</syntaxhighlight>

Але resource-level checks часто все одно треба робити в service layer.; {

 "scope": "article:read article:write",
'''істотно:''' feature flag не повинен замінювати security-critical authorization check.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

 return projectRepository.update(projectId, input);
}
користувач системи із tenant A має змогу відкрити resource tenant B через зміну ID в URL.;== Authorization у Cloud IAM ==
'''Access token''' — токен, який замовник використовує для доступу до protected resource.; }
користувач системи має змогу переглядати документ,
і документ не позначений як confidential.;== Authorization і Audit Logs ==
'''Критично:''' IDOR — одна з найпідступніших authorization-помилок, бо endpoint має змогу виглядати абсолютно нормальним.; Authorization відповідає:

складних правил забезпечується через '''істотно:''' ABAC корисний; додатково реалізовано але його важче пояснювати, тестувати й audit-ити.; Приклад:
== Authorization у CMS ==
'''ACL''' або '''Access Control List''' — список доступів для конкретного ресурсу.; '''RBAC''' або '''Role-Based Access Control''' — модель авторизації, де доступ визначається ролями.;</div>
'''Критично:''' authorization bug часто не видно в happy path тестах.; const project = await projectRepository.findById(projectId);
</div>
<syntaxhighlight lang="text">

<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

як ілюстрація, користувач системи має змогу бути справжнім власником акаунта, але це не означає, що він має право бачити чужий invoice, видаляти чужий проєкт або відкривати admin panel.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

</div>

істотно: проста authorization-модель має змогу бути хорошою.; * Role;

ClusterRole;
RoleBinding;
ClusterRoleBinding;
ServiceAccount;
verbs;
resources;
namespaces.; переважні аспекти

if (!canUpdateProject(currentUser, project)) {
Рекомендовано:

</syntaxhighlight>

користувач системи є собою власником invoice;
користувач системи має спеціальний permission для перегляду всіх invoices.; Чи функціонує deny by default?;

Приклади:

Корисні сигнали:

Підказка: найкраща перевірка authorization-моделі — спробувати описати її простими реченнями: “Хто має змогу що робити з яким ресурсом?”

- project.update

owner permissions;
group permissions;
read/write/execute;
ACL;
file ownership;
directory permissions;
shared folder permissions.; * Матеріали щодо OWASP access control risks, IDOR, privilege escalation і least privilege.; API authorization перевіряє доступ до endpoints і resources.;== Типові помилки початківців ==

користувач системи або сервіс має отримувати тільки ті права,

Приклади причин:

Проблеми:

- project.read

ризик випадкових змін;
шкоду від зламаного акаунта;
privilege escalation;
insider risk;
наслідки помилки;
доступ до чутливих даних.; - article.create

Краще:

Multi-tenant API

- project.delete

відділяти authentication від authorization;
перевіряти доступ на backend;
використовувати deny by default;
застосовувати least privilege;
перевіряти доступ до конкретного resource;
писати негативні authorization tests;
не довіряти client-side checks;
не зберігати зайві права в token без контролю;
робити audit logs для важливих дій;
регулярно переглядати roles і permissions;
уникати однієї ролі admin для всього;
обмежувати service accounts;
перевіряти tenant boundary;
документувати permission model;
не показувати зайву інформацію в error responses;
тестувати IDOR-сценарії.;

</div>

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''істотно:''' ownership-перевірка має бути на backend.;== Authentication vs Authorization ==
</div>
Roles:

'''Практична роль:''' OAuth scopes — це спосіб сказати: “цей застосунок має змогу читати календар, але не має змогу видаляти події”.;== Backend Authorization ==

== Mass Assignment ==
</div>
- Admins: manage

Editor не має змогу змінити billing settings.;</div>

== Ризики поганої авторизації ==

{

* user identity;
* scopes;
* roles;
* permissions;
* expiration;
* issuer;
* audience;
* client application;
* tenant;
* session context.;== Permission ==
</div>
</div>

== Centralized vs Decentralized Authorization ==

</div>

-rw-r----- user group report.txt
Policy має змогу відповідати на питання:
== Policy Engine ==
{{SEO
|title=Authorization — авторизація, права доступу, ролі, permissions, RBAC, ABAC і безпека застосунків
|description=Authorization — Wiki-стаття про авторизацію як перевірку прав доступу після authentication. Розглянуто authentication vs authorization, permissions, roles, RBAC, ABAC, ACL, OAuth scopes, JWT claims, policy engine, least privilege, access control, API authorization, database authorization, frontend і backend перевірки, security risks, IDOR, privilege escalation, переваги, обмеження, цікаві факти і хороші практики.
|keywords=Authorization, авторизація, access control, authentication vs authorization, permissions, roles, RBAC, ABAC, ACL, OAuth scopes, JWT claims, policy engine, least privilege, privilege escalation, IDOR, API authorization, backend authorization, frontend authorization, access token, security, application security
|alternativeTo=доступ без перевірки прав; hardcoded admin checks; одна роль admin для всіх; перевірка доступу лише на frontend; shared passwords; ручне керування доступом без audit; відкриті API без permissions; надмірні права користувачів; security by obscurity; хаотичні rules без policy model
}}
|-
| Authentication
| Хто ти?; !; if (!project) {
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

Це product authorization або entitlement management.;</div>

* приховати недоступну кнопку;
* показати правильне меню;
* вимкнути action;
* перенаправити з недоступної сторінки;
* показати повідомлення про доступ;
* адаптувати navigation.; * Практики cloud IAM, Kubernetes RBAC, database permissions, audit logging і multi-tenant SaaS security.; Складніша модель потрібна, якщо є собою:
Якщо authentication відповідає на питання “хто ти?”, то authorization відповідає на питання “що тобі дозволено?”.; Приклад policy:
Feature flags можуть впливати на доступ до функцій, але не завжди є собою повною authorization-моделлю.;</div>
Приклад ідеї:

Чи має цей користувач системи право використати цю функцію?;

</syntaxhighlight>

Row-Level Security

Чи не довіряємо role з client payload?; істотно: успішний login не означає автоматичний доступ до всіх ресурсів.; Її потрібно захищати сильніше, ніж звичайний user dashboard.; Чи є собою resource-level checks?; без ускладнень розпарсити token недостатньо.; * бізнес-застосунків;

admin panels;
SaaS;
CMS;
CRM;
enterprise systems;
командних workspace;
простих і середніх моделей доступу.;

- Bob: read

Deny by Default

Чи перевіряється tenant boundary?;

Цей підхід особливо важливий для: Якщо немає правила — заборонити.; Після цього кожна важлива дія все одно має перевірятися окремо.; Permissions: Види: IDOR або Insecure Direct Object Reference — вразливість, коли користувач системи має змогу отримати доступ до чужого ресурсу, змінивши ідентифікатор.; Приклад

враховувати user/tenant у cache key;
не кешувати sensitive responses без потреби;
правильно ставити cache headers;
invalidation після зміни permissions;
перевіряти authorization перед віддачею cached data.; * застосунок маленький;
є собою тільки owner і viewer;
немає sharing;
немає sensitive data;
немає enterprise customers;
немає team workspaces;
немає admin panel;
програмний продукт ще MVP.; * owner має змогу читати й писати;
group має змогу читати;
others не мають доступу.; Авторизація потрібна майже в кожному застосунку, де є собою акаунти, ролі, приватні інформаційні дані, API, адміністративні панелі, платежі, документи, файли, команди, організації або різні рівні доступу.; throw new ForbiddenError();

Authorization і Caching

Least privilege зменшує:

Role — набір permissions, який відповідає певній функції користувача.; {| class="wikitable"

GRANT SELECT ON invoices TO reporting_user; У CMS авторизація керує тим, хто має змогу створювати, редагувати, публікувати й видаляти контент.; Погана авторизація має змогу призвести до:

tenant;
workspace;
subscription plan;
seats;
feature flags;
team membership;
invitations;
sharing;
billing permissions;
data exports.; Назва `401 Unauthorized` історично трохи плутає, бо фактично часто означає “не authenticated”.;

Session-based authorization часто застосовується в: </syntaxhighlight>

Authorization і Observability

Audit logs фіксують важливі дії доступу.; Головне правило: кожна важлива дія має відповідати на три питання: хто діє, що хоче зробити й над яким ресурсом.;== Висновок ==

</syntaxhighlight>

- billing.manage

team.member.invite

Admin;
Owner;
Manager;
Editor;
Viewer;
Member;
Billing Admin;
Support Agent;
Auditor;
Developer;
Operator.;

Authorization впливає на user experience.;

істотно: middleware має змогу перевірити permission, але не завжди знає, чи користувач системи має доступ саме до конкретного project або document.; Authorization має перевіряти:

без ускладнень показує “Error”;
показує кнопку, яка завжди завершується 403;
розкриває існування приватного ресурсу;
не пояснює, яку роль потрібно мати.; Критично: “Дамо admin, щоб не було проблем” — один із найшвидших шляхів до серйозної проблеми безпеки.;

</syntaxhighlight> deny

Але навіть у простій моделі потрібно мати:

складних enterprise rules;
microservices;
centralized authorization;
audit;
compliance;
ABAC;
policy-as-code.; /invoices/1001

користувач системи із organization A не має змогу отримати доступ до project organization B, навіть якщо знає ID project.;

<syntaxhighlight lang="text">

Kubernetes RBAC має:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
- Alice: read, write

'''істотно:''' кеш має змогу випадково обійти authorization, якщо його неправильно спроєктувати.; Питання
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
|-
| Viewer
| Переглядати документи
|-
| Editor
| Переглядати й редагувати документи
|-
| Admin
| Керувати користувачами й налаштуваннями
|}

'''Authorization''' — це ключова частина безпеки застосунків, яка визначає, хто має право виконувати конкретні дії над конкретними ресурсами.; Потрібно перевіряти:

project.settings.update

* хто має змогу виконати дію;
* з яким ресурсом;
* за яких умов;
* які атрибути враховуються;
* які винятки існують.; '''Практична роль:''' RLS переносить частину авторизації ближче до даних, а не лише до application code.; Вона відрізняється від authentication: спочатку платформа встановлює особу користувача, а потім перевіряє його права.;== RBAC ==
- Team Finance: read

tenant id;
organization membership;
workspace role;
resource ownership;
cross-tenant isolation;
admin boundaries;
billing permissions;
invitation rules.; "role": "admin"

;== Multi-Tenant Authorization == Error Codes: 401 і 403 Практична роль: checklist сприяє знайти authorization gaps до того, як їх знайде хтось інший.; * У SaaS authorization часто складніша за authentication.; Коли використовувати Ownership — модель, де доступ залежить від власника ресурсу.; Author має змогу створювати drafts, Editor має змогу редагувати чужі статті, Publisher має змогу публікувати, Admin має змогу керувати plugins і users.; Роль DELETE /api/projects/123 draft.create; article.edit; article.publish; article.delete; media.upload; comment.moderate; user.manage; settings.update.; Перевага: хороша авторизація надає можливість давати людям рівно той доступ, який їм потрібен, і не більше.; істотно: Kubernetes permissions треба давати обережно.; Практична порада: складність авторизації має рости разом із реальними потребами продукту, а не з фантазіями про майбутні enterprise-функції.; - media.upload Приклад: Приклад ідеї: але не має змогу змінювати user role.; Permissions: Практична роль: session-based підхід зручний, коли сервер контролює стан входу користувача.; Only project owners can delete a project.; Access token має змогу містити або посилатися на: return invoice.userId === user.id \|\| user.permissions.includes("invoice.view_all"); багато ролей; багато типів ресурсів; teams або organizations; multi-tenant architecture; sharing; admin panel; billing roles; external integrations; compliance; sensitive data; field-level permissions; approval workflows; enterprise customers.; Admin: Policy engine корисний для: REVOKE DELETE ON invoices FROM reporting_user; - Editor Access control — ширше поняття, яке охоплює правила, механізми й процеси керування доступом.;</syntaxhighlight> `user.read`; `user.update`; `project.create`; `project.delete`; `invoice.view`; `invoice.refund`; `settings.manage`; `admin.access`; `report.export`; `billing.manage`.; Часто потрібні окремі ролі для billing, users, security, content і integrations.; * Authentication Access Control Application Security RBAC ABAC ACL OAuth JWT API Security Least Privilege Privilege Escalation IDOR OWASP Cloud IAM Kubernetes RBAC Database Security Row-Level Security Audit Log SaaS Multi-tenant Architecture Frontend Backend Security Testing Приватність даних Документація Authorization Авторизація Access Control Authentication vs Authorization Permissions Roles RBAC ABAC ACL OAuth Scopes JWT Claims Policy Engine Least Privilege Privilege Escalation IDOR API Authorization Backend Authorization Frontend Authorization Access Token Security Application Security Документація

Access Control

Authorization у Kubernetes

переважні аспекти хорошої авторизації

JWT Claims

Authorization і Feature Flags

Authorization у SaaS

Authorization у файлових системах

Policy

Cloud infrastructure

Див.; додатково

SaaS workspace

Authorization Testing

Приклад ownership check

Admin Authorization

Authorization і UX

ABAC

Коли потрібна складна authorization-модель

IDOR

Цікавий факт

Хороші практики Authorization

Multi-tenant API

Row-Level Security

Deny by Default

Authorization і Caching

Authorization і Observability

Error Codes: 401 і 403