Performance impact of PDP as Filter
PDP as Filter has poor scalability for large candidate sets; repeated PDP calls multiply integration overhead.
OWASP Cheat Sheets · all subjects
application_security/authorization
40 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Performance impact of PDP as Filter with batching
PDP as Filter with batching reduces round-trips; still retrieves more data than needed.
Performance impact of Authorized Data Set
Authorized Data Set for low/medium cardinality is efficient with a single round-trip. Authorized Data Set for high cardinality requires pagination or streaming and risks large response payloads.
Performance impact of Authorization Filter
Authorization Filter is usually best for large queryable datasets and shifts cost to the data source.
Performance impact of Remote PDP vs In-process PDP
Remote PDP adds network and serialization overhead per call. In-process/Sidecar PDP reduces integration overhead but increases local CPU/memory pressure.
Performance impact of decision caching
Decision caching reduces latency but may produce stale decisions if invalidation is not aligned with freshness and latency requirements.
Performance impact of fail-closed fallback strategy
Fail-closed fallback strategy preserves security posture but may degrade availability.
Caching and memoization in PDP
Caching and memoization can reduce decision latency significantly — many PDPs support caching of evaluation results for deterministic inputs. These optimizations can reduce latency but can lead to outdated decisions and require robust cache invalidation logic.
Fallback strategies and timeouts for PDP
Fallback strategies and timeouts determine system behavior when PDPs are slow or unavailable. The choice between fail-closed, fail-open, and graceful degradation affects both perceived performance and security posture.
Authorization request canonical form
The canonical form of an authorization request is: 'Can subject X perform action Y on object Z?' In the simplest case, the result of such a request is an atomic permit or deny.
Single Decision Request definition
A Single Decision Request is one authorization query sent to the PDP, returning one output data object. At minimum, a request is a triplet — (subject, action, object) — and often a quadruplet: (subject, action, object, context), where context carries additional information such as environment attributes, risk signals, or request metadata relevant to the decision.
Batch Request definition and use cases
A Batch Request bundles multiple independent Single Decision Requests into one PDP call, receiving one output data object per query in return. Batch calls are typically used in two situations: (1) Multiple actions for one object — determining which actions a subject may perform on a specific resource, for example to decide which buttons to render; (2) One action across a known, bounded candidate set — filtering a small set of search results where the same action is checked for each item.
Output data cardinality levels
Output data cardinality describes the structure and size of the decision object returned by the PDP. Three levels are common: (1) Low — simple decisions with minimal metadata, example { "decision": "permit" }; (2) Medium — decisions include multiple structured attributes or small result sets, example { "allowed_projects": ["A", "B"] }; (3) High — decisions include large or complex result sets, example { "resources": ["doc1", "doc2", ..., "doc5000"] }.
PDP as Filter pattern - definition and characteristics
PDP as Filter (Brute-Force Lookup) pattern: The PEP retrieves all potentially relevant data from a data source and checks each item against the PDP — either through individual Single Decision Requests or through Batch Requests. Permitted items are included in the final result. Pros: Simple to implement, works with any PDP type, easy to debug and monitor. Cons: High latency and poor scalability for large candidate sets due to repeated PDP calls, increases resource consumption by retrieving more data than needed, tightly couples the PEP with service business logic, makes externalizing the PEP difficult or impossible, policy changes may require service redeployments or refactorings. Typically suited for: Small candidate sets where Authorized Data Set and Authorization Filter are not supported by the PDP.
Authorized Data Set pattern - definition and characteristics
Authorized Data Set pattern: The PEP makes a single request to the PDP, and the PDP returns the complete set of resources the subject may access, such as a list of permitted object IDs. The PDP constructs this result based on policy logic and available attributes. Pros: No candidate set needs to be retrieved in advance, reduces round-trips by returning all results at once, simplifies PEP logic — the PDP handles the complexity of determining the authorized set, well-suited for ReBAC or NGAC PDPs that can leverage internal graph data to compute permitted resources. Cons: Externalizing the PEP to an external proxy is only feasible for low to medium cardinality output data sets, might complicate error handling and monitoring of data access, requires pagination or streaming for larger output data sets, results in complex policies for PDPs implementing PBAC approaches, not supported by every PBAC PDP implementation. Typically suited for: Low to medium output cardinality, especially when the PDP can efficiently compute permitted resources from internal relationship or graph data.
Authorization Filter pattern - definition and characteristics
Authorization Filter pattern: The PEP calls the PDP, and the PDP returns a filter expression — such as a query predicate or attribute-based condition. The PEP applies this filter during data retrieval, so only permitted data is fetched in the first place. Pros: No candidate set needs to be retrieved in advance, highly efficient for large datasets — filtering happens at the data source, scales well with high output cardinality, reduces PDP load, enables flexible PEP placement — as part of the service or as an external proxy. Cons: Not supported by every PDP (ReBAC and NGAC PDPs do not support that at all), requires the PEP or data access layer to apply the returned filter correctly, can complicate error handling, monitoring, and diagnosis of access decisions. Typically suited for: High output cardinality and queryable resources where authorization constraints can be translated into data-source filters.
Authorization pattern selection - quick reference table
Scenario to common approach mapping: (1) Single access check → Single Decision Request; (2) Multiple actions for one object (e.g., render UI controls) → Batch Request; (3) One action across a small, known candidate set → PDP as Filter; (4) Authorized set must be derived — low/medium cardinality → Authorization Filter or Authorized Data Set; (5) Authorized set must be derived — high cardinality → Authorization Filter or paginated Authorized Data Set.
Policy evaluation latency factor
Policy evaluation latency is the time the PDP takes to compute a decision. It depends on the number and complexity of policies, the amount of input data evaluated, and on whether the PDP must enumerate or filter large result sets internally.
Policy output handling performance impact
Policy output handling adds work proportional to output cardinality. The selected output handling pattern affects the time required to process and apply the result.
PDP integration overhead components
PDP integration overhead covers network latency, TLS handshake, DNS resolution, and serialization costs for each PDP call. Protocol choices (e.g., HTTP/1.1 vs. HTTP/2 vs. gRPC) can further influence this. In-process PDPs minimize this overhead but may increase local resource contention. For patterns that make many PDP calls per request — such as PDP as Filter without batching — this overhead multiplies. Batch requests directly reduce this multiplication effect.
Runtime resource contention in PDP deployment
Runtime resource contention is especially relevant when a PDP is co-located with edge components, gateways, or application services ("Busy Neighbor" effect). PDPs are typically CPU- and memory-intensive. Shared compute resources without isolation can degrade throughput for both the PDP and the host component. This is especially relevant when integrating a PDP into an edge component (either embedded or as a sidecar), which is often optimized for high IOPS throughput. In such cases, embedding a PDP introduces trade-offs between CPU-bound policy evaluation and I/O-heavy request processing.
Performance impact of Batch Request
Batch Request reduces round-trips; increases payload size.
PEP must not leak authorization criteria into request
Patterns that leak authorization criteria into the request — such as passing role names or permission flags directly — are antipatterns, as they couple the PEP to policy internals and undermine the separation of concerns that makes authorization maintainable. The PEP should supply who is asking, what they want to do, and what they want to do it on — not criteria for how the decision should be made. The policy logic in the PDP is solely responsible for evaluating those criteria.
Data sources distinct from Policy Information Points
Data sources are the application's own stores — databases, APIs, or services that hold the resources being filtered or queried. They are distinct from Policy Information Points (PIPs), which supply attributes used as input to policy evaluation.
Decentralized Service-Level Authorization pattern definition
In this pattern, functional components from the reference architecture are implemented directly within each microservice. Policy Decision Points (PDPs), Policy Enforcement Points (PEPs), and Policy Information Points (PIPs) may be embedded into the service logic. Access control rules are typically implemented using native language constructs such as if/else statements, either inline with business logic functions or via abstraction mechanisms such as interceptors. When a microservice receives a request containing authorization data, it evaluates whether access should be granted, which may involve querying other services for additional attributes before reaching a decision.
Decentralized Service-Level Authorization pros
Decentralized Service-Level Authorization provides: (1) Familiar development model - developers use the same language and tools they already know; (2) Framework support - many libraries and frameworks exist to reduce boilerplate; (3) Rapid prototyping - policy logic is implemented directly in code; (4) Team autonomy - fits well with independent team ownership; (5) High performance - policy evaluation is done in-memory within the microservice; (6) Full context awareness - the service has access to runtime data, business logic, and domain models; (7) Failure isolation - if all required attributes are available locally or cached, failures in external systems do not impact decision-making.
Decentralized Service-Level Authorization cons
Decentralized Service-Level Authorization introduces significant drawbacks: (1) Scattered logic - authorization requirements spread across multiple services, leading to code duplication, increased complexity, and maintenance overhead (classic 'Hardcoded Rules' antipattern); (2) Role explosion - without an abstraction layer between business roles and implementation, systems accumulate many similar but inconsistent roles ('Code Against the Role' antipattern); (3) Deprived governance - autonomous teams interpret and implement policies differently, making consistent governance nearly impossible; (4) No central auditability - impossible to answer 'before-the-fact' questions like 'Who has access to what, and when?'; (5) Inconsistent monitoring - logging and audit trails vary widely across services; (6) Coverage gaps - many frameworks do not expose ways to integrate access control into certain auto-exposed endpoints, leading to unintended public exposure of sensitive endpoints. These cons often result in 'accept by default' behavior, ultimately leading to broken access control vulnerabilities.
Centralized Service-Level Authorization pattern definition
This pattern aims to reduce complexity, improve time to market, and establish governance by decoupling policy logic from service code. Authorization rules are defined independently of the microservice code and can reside in a dedicated policy repository or be colocated with the service code. The essential aspect is that policies are decoupled from the service code rather than intertwined with it. The actual enforcement of access decisions still takes place locally to each microservice. The PDP can be implemented as a library (e.g., Casbin), as a local sidecar process (e.g., Open Policy Agent), or as an external, centrally managed PDP. Authorization rules are defined using the PDP's domain-specific language (e.g., Rego for OPA) rather than being hardcoded into service logic.
Centralized Service-Level Authorization pros
Centralized Service-Level Authorization provides: (1) Policy governance - policies can be centrally defined, versioned, reviewed, and audited, independent of the service's implementation language; (2) Policy layering - allows both global (security team-defined) and local (service team-defined) policies to coexist; (3) Improved monitoring - all decisions can be consistently logged and monitored; (4) Team autonomy - teams remain responsible for their services and policies with local enforcement and minimal external dependencies; (5) Enhanced testability - authorization logic can be tested independently of microservice business logic.
Side-Car-Proxy-Based Authorization pattern
This is a variant of Edge-Level Authorization (Modern) where the PEP is deployed alongside the microservice as a dedicated proxy, intercepting and controlling all inbound traffic to that service. This approach shares many of the same advantages and drawbacks as the edge-level model. However, operational complexity increases, as each service gains an additional moving part. Furthermore, observability becomes fragmented, since monitoring is limited to individual services unless all services in a given context adopt the same pattern.
Centralized Service-Level Authorization cons
Centralized Service-Level Authorization introduces challenges: (1) Policy distribution complexity - policies are decoupled from code, requiring mechanisms to deploy the correct version of each policy to appropriate service instances; (2) Context sharing - PDPs do not inherently have access to microservice context; developers must design mechanisms to assemble and pass right attributes into the PDP; (3) Coverage gaps - some frameworks expose endpoints by default without offering hooks for policy enforcement; common examples include health and metrics endpoints (Spring Boot Actuator), auto-generated documentation routes (FastAPI, OpenAPI UIs), or static routes in frameworks like Express.js; (4) Incomplete enforcement observability - while policy decisions are logged, there is often no visibility into whether those decisions were correctly enforced across all code paths. Due to these gaps, 'accept by default' behaviors remain a real risk, leading to broken access control vulnerabilities.
Edge-Level Authorization (Classic) pattern definition
This pattern moves access control to the system's perimeter, typically implemented via API gateways, ingress controllers, or reverse proxies. Since authorization must follow authentication, this pattern tightly couples authentication and authorization at the network boundary. Gateways or proxies serve as the PEP and either evaluate policies locally using embedded logic or delegate decisions to an external PDP. All external traffic flows through the edge component, making this the first pattern that guarantees every inbound request is observed and subject to access control logic.
Edge-Level Authorization (Classic) pros
Edge-Level Authorization (Classic) provides: (1) Consistent enforcement - all inbound requests pass through a centralized enforcement point, ensuring uniform application of policies and reducing the likelihood of unprotected endpoints ('no accept by default'); (2) Policy governance - policies can be centrally defined, versioned, reviewed, and audited, independent of the service's implementation language; (3) Policy layering - allows both global (security team-defined) and local (service team-defined) policies to coexist; (4) Best observability - all external access attempts are visible and can be logged centrally, supporting effective monitoring, alerting, and forensics.
Edge-Level Authorization (Classic) cons
Edge-Level Authorization (Classic) introduces challenges: (1) Socio-technical challenges - API gateways are operated by infrastructure or platform teams; development teams cannot directly manage authorization policies or authentication configurations, requiring close coordination between developers and operations/security; (2) Policy distribution complexity - policies are decoupled from code, requiring mechanisms to deploy correct versions; (3) Authentication limitations - edge components only support a single authentication configuration per listener or route group; supporting multiple identity providers, per-endpoint authentication flows, or advanced patterns (dynamic consent, step-up authentication, conditional logic) is difficult or impossible; (4) Context sharing - edge components only have access to request-level attributes (headers, paths, IPs), making fine-grained or business-context-sensitive decisions difficult; (5) Enforcement blind spots and defense-in-depth violations - since edge only governs ingress traffic, internal traffic (service-to-service calls) or network misconfigurations may bypass enforcement entirely.
Edge-Level Authorization (Modern) pattern definition
This pattern evolves classic edge-level authorization to overcome its key limitations. While enforcement still occurs at the perimeter via proxies or gateways, this approach allows per-service customization through service-specific rules — declarative definitions of how identity and context are gathered, how authorization is performed, and how decisions are propagated — forming explicit authorization contracts. These contracts manifest as structured, signed data (e.g., JWT claims or enriched signed headers) that edge proxies or gateways relay to downstream services. This explicit propagation of authorization context ensures that internal service-to-service calls rely on a trusted, verifiable authorization boundary, addressing enforcement blind spots and defense-in-depth violations. By making authorization an explicit API-level contract, teams can confidently decentralize enforcement without creating single points of failure or gaps in access control.
Edge-Level Authorization (Modern) pros
Edge-Level Authorization (Modern) provides: (1) Consistent enforcement - uniform application of policies at a centralized point prevents unprotected or overlooked endpoints; (2) Policy governance - policies remain versioned, reviewed, and auditable, often authored centrally but can be referenced declaratively in service-specific contracts; (3) Best observability - all external access attempts are visible and can be logged centrally; (4) Rapid prototyping - through authorization contracts, teams can experiment with different authorization models without relying on infrastructure components; (5) Context sharing - the proxy can fetch contextual data from arbitrary PIPs, enabling context-sensitive decisions based on domain-specific attributes, object metadata, or subject state; (6) Service autonomy - authorization contracts empower microservice teams to define their own access control needs declaratively, supporting domain-driven service ownership; (7) Authorization context propagation - the system can rewrite identity and authorization responses from the PDP into formats matching each service's expectations (structured JWTs, plain or signed headers); (8) Secure by default - the use of declarative contracts and centralized enforcement reduces misconfiguration risks and prevents implicit access grants.
Edge-Level Authorization (Modern) cons
Edge-Level Authorization (Modern) introduces challenges: (1) Policy distribution complexity - ensuring the correct version of a policy is evaluated in the context of the specific service version requires additional coordination, mainly depending on PDP capabilities and tooling; (2) Contract governance - while authorization contracts empower teams with autonomy, it requires clear guidelines and automated validation tools to prevent misconfiguration or misuse.
PDP Deployment & Integration Options comparison table
The choice of PDP deployment significantly impacts performance, auditability, and supported authorization models. Comparison across three approaches: (1) Embedded PDP: Location - as a library, Latency - no impact, Before the Fact Audit - limited, Access Control Models - PBAC (e.g., Casbin), Dependencies - none (self-contained); (2) Side-Car PDP: Location - as local side-car process, Latency - very low latency, Before the Fact Audit - limited, Access Control Models - PBAC (e.g., OPA), Dependencies - none (self-contained); (3) External PDP: Location - separate PDP service, Latency - higher latency due to network hops, Before the Fact Audit - possible system wide, Access Control Models - PBAC, ReBAC, and NGAC (e.g., OPA, OpenFGA, SpiceDB), Dependencies - Relies on PDP service availability.
PDP and authorization pattern component definitions
Policy Decision Point (PDP) is the component that makes authorization decisions. Policy Enforcement Point (PEP) is the component that enforces those decisions. Policy Information Point (PIP) is the component that provides attributes and context needed for authorization decisions.
Data source integration for authorization decisions
The need to fetch or inject data required for policy evaluation introduces operational challenges across all authorization patterns. This responsibility may lie with the PEP (e.g., a service or edge proxy) or the PDP itself. Accessing PIPs at runtime can complicate network configurations, conflict with segmentation or firewall policies, and broaden the system's attack surface. These concerns require careful architectural consideration.