Application authorization decides whether an authenticated principal may perform one action on one resource in one context. This bundle defines a deny-by-default decision boundary, object-level checks, role and relationship modeling, policy evolution, and adversarial tests. Unlike Auth Sessions, JWT, and OAuth, it starts after identity is known; unlike IAM and Least Privilege, it governs application resources rather than cloud administration.
Önerilen yol haritası
Pathrule her parçayı eşleşen yola yerleştirir; böylece asistanınız onu yalnızca ait olduğu yerde görür. İçe aktardığınızda kapsam böyle kurulur; isterseniz çalışma alanınızda değiştirebilirsiniz.
/ çalışma alanı kökü
src/
authorization/
Every protected operation asks one deny-first decision API
Roles, attributes, and relationships solve different dimensions
Authorization decisions are explainable without exposing the graph
domain/
Authorize the loaded object and its current relationships
tests/
authorization/
Authorization tests prove denials and relationship edges
review-authorization-model
Kurallar
4
Every protected operation asks one deny-first decision API/src/authorizationyüksekkatıHandlers call a central decision boundary with principal, action, resource, tenant, and trusted context before side effects begin.
1
Authorization is a server-side precondition for every protected read and write, not a UI feature or a role-name convention. Route handlers, jobs, GraphQL resolvers, batch actions, and internal tools call one decision interface with the authenticated principal, canonical action, loaded resource, trusted tenant, and current policy context. Any missing input, evaluation error, or unknown action denies.
2
3
- Resolve principal and tenant from authenticated server state, never from an unverified request field.
4
- Name actions from business capabilities such as invoice.approve rather than HTTP verbs or screen names.
5
- Return a stable allow or deny result with policy version and reason code, without leaking sensitive relationship data.
6
- Complete authorization before writes, external calls, queues, or protected response bytes.
7
8
Verification: Remove each input, use an unknown action, inject an evaluator failure, and call the same operation through every transport; confirm all paths deny consistently.
Authorize the loaded object and its current relationships/src/domainyüksekkatıPermission checks bind to the exact server-loaded resource, parent, tenant, and relationship state used by the operation.
1
Checking permission to access a collection, route, or resource type does not authorize a specific object. Load the object through a tenant-safe lookup, derive its immutable identifiers and relevant parents, then evaluate the action against that exact state. Recheck inside the same consistency boundary when relationships or ownership can change concurrently.
2
3
- Reject identifiers that resolve outside the authenticated tenant without revealing whether the object exists.
4
- Apply checks to nested resources, exports, bulk selection, indirect references, and side-channel metadata such as counts.
5
- Avoid post-filtering unauthorized rows after an unbounded query; constrain reads at the data or policy boundary.
6
- Treat create operations as authorization against the intended parent and attributes, not a resource that does not exist yet.
7
8
Verification: Swap object, parent, tenant, group, and owner ids across otherwise valid requests; confirm no content, timing detail, count, or mutation crosses the boundary.
Policy changes invalidate affected authorization decisions/src/authorizationyüksekkatıCached decisions are bounded by principal, action, resource, context, policy version, relationship version, and a deliberate lifetime.
1
Authorization caches can turn revoked membership, changed ownership, disabled accounts, or new policy into continuing access. Cache only after proving the complete decision key, and include every input that can change the result: principal, action, resource, tenant, relevant context, policy version, and relationship or data version. Prefer short request-scoped memoization for complex decisions.
2
3
- Invalidate or version-bust on membership, role, ownership, policy, account, and tenant status changes.
4
- Never share a cached allow across principals or resources because the public response looks identical.
5
- Define failure behavior and maximum stale access explicitly; evaluator unavailability must not silently allow.
6
- Measure hit rate, decision age, invalidations, and stale-deny or stale-allow test outcomes without logging sensitive tuples.
7
8
Verification: Cache an allow, revoke each underlying relationship, and race reads with the change; confirm access ends within the documented bound.
Authorization tests prove denials and relationship edges/tests/authorizationortakatıThe matrix covers every action across allowed, denied, cross-tenant, missing, stale, indirect, and concurrent relationship cases.
1
Happy-path role tests do not expose broken object-level authorization. Build a policy matrix from principal types, actions, resource states, ownership, group and hierarchy relationships, tenant boundaries, and exceptional attributes. For every allow, include the nearest denial created by changing one fact.
2
3
- Test direct endpoints, nested routes, batch operations, exports, background jobs, and alternate transports that reach the same capability.
4
- Include deleted, disabled, suspended, unowned, transferred, shared, inherited, and cyclic relationship cases.
5
- Assert both the decision and the absence of protected fields, counts, timing clues, and side effects.
6
- Run policy-model tests and integration tests against the real data loader and evaluator configuration.
7
8
Verification: Generate the action-resource matrix from registered capabilities and fail CI when a new protected action has no explicit allow and deny cases.
Hafıza kayıtları
2
Roles, attributes, and relationships solve different dimensions/src/authorizationRBAC groups stable job capabilities, ABAC adds trusted context, and ReBAC expresses resource relationships such as owner, member, parent, or viewer.
1
Use roles for stable bundles of capabilities, not for every team, customer, document, or exception. Use trusted attributes for contextual conditions such as account status, region, data classification, or approved time window. Use relationships when access depends on how a principal connects to a resource through ownership, membership, hierarchy, delegation, or sharing. Complex applications usually combine these dimensions behind one decision API.
2
3
Do not copy relationship facts into ever-growing role names or accept authorization attributes from the client. Define tuple or relation ownership, cardinality, inheritance, cycle behavior, and deletion semantics. Keep policy readable enough that product and security owners can review the intended matrix. See /src/domain for canonical resource loading and /tests/authorization for edge coverage.
Authorization decisions are explainable without exposing the graph/src/authorizationDecision records retain safe reason codes, policy versions, and resource references while sensitive membership and policy internals stay protected.
1
Support, incident response, and audit need to know why access was allowed or denied, but returning raw policy traces can reveal group membership, hidden resources, tenant structure, or security rules. Define stable internal reason codes and a privileged explanation path separate from the ordinary application response.
2
3
Record principal, canonical action, protected resource reference, tenant, decision, policy version, evaluator status, and safe reason with correlation identifiers. Minimize attributes and relationship data in logs, apply retention and access controls, and never make the explanation record itself a bypass path. Aggregate denial categories for monitoring without high-cardinality sensitive labels. See the Security Audit Logging pattern for evidence integrity and access review.
Beceriler
1
review-authorization-model/tests/authorizationReview actions, resources, roles, attributes, relationships, loaders, caches, denials, and policy migrations as one authorization system.
1
---
2
name: review-authorization-model
3
description: Review an application authorization model and its enforcement paths for bypass and drift.
4
---
5
6
# Review Authorization Model
7
8
1. Inventory protected actions and every transport, job, export, batch path, and internal tool that can invoke them.
9
2. Map each action to canonical resource loading, tenant derivation, required roles, trusted attributes, relationships, exceptional states, and default denial.
10
3. Trace one allow and the nearest deny through handler, policy decision, data query, side effects, cache, and audit evidence.
11
4. Test cross-tenant ids, indirect references, nested and bulk operations, stale relationships, evaluator failure, policy migration, and concurrent ownership change.
12
5. Record uncovered capabilities, ambiguous policy, sensitive explanations, cache risks, owner, and the evidence from a clean rerun.
13
14
The review is complete only when every protected capability has one enforceable decision boundary and explicit negative tests.
Neden bu kalıp
Agents scatter role-name checks through handlers, trust tenant or owner ids from requests, and authorize list pages while missing the individual object mutation path.
Hedef kitle: Teams building multi-user or multi-tenant applications with role, attribute, ownership, group, hierarchy, or sharing permissions.
Asistanınızı şunlardan alıkoyar:
Authenticated users accessing another tenant's object by changing an id
Role strings becoming an unreviewable substitute for resource policy
Stale authorization caches preserving access after a relationship changes
Pathrule