What is the difference between asking whether a request can succeed and whether it should succeed?

Can it succeed asks whether the application technically returns data or completes an action. Should it succeed asks whether the access matches the role, ownership, and policy boundaries the system is meant to enforce. For IDOR testing, the second question is the meaningful one because many serious flaws look valid at the protocol level but violate authorization intent.

Why This Matters for Security Teams

The difference between success and legitimacy is the difference between a system that merely responds and a system that enforces policy. That distinction matters in IDOR testing, but it also applies to API authorisation, workflow abuse, and broken object access in modern applications. A request can return a valid record, perform a state change, or expose metadata while still violating the intended trust boundary. That is why NHI Management Group treats “should it succeed” as the real security question.

Teams often miss this because functional testing confirms that the feature works for the intended user, while security testing must prove that the same action fails for everyone else. The control objective is not just availability or correctness, but enforcement of ownership, role, and context. The NIST Cybersecurity Framework 2.0 frames this well through access control, protective safeguards, and continuous verification of trust assumptions. That maps directly to requests that appear successful but should be rejected.

Practitioners also need to remember that authorization failures often look like ordinary application behaviour. A verbose 200 response, a partial object leak, or an action that only changes one field can still expose sensitive data or break policy. In practice, many security teams encounter object-level authorization flaws only after a real incident or a structured test campaign, rather than through intentional design review.

How It Works in Practice

Testing “can it succeed” checks technical reachability. Testing “should it succeed” checks whether the server enforces the correct decision logic for the caller, the object, and the operation. In a strong design, these are separate questions. A request may be syntactically valid, authenticated, and routed correctly, yet still be denied because the subject does not own the resource, lacks the right role, or is outside an approved workflow state.

Effective review usually combines functional and authorization checks across the full request path. That means validating object identifiers, comparing session context to server-side policy, and confirming that the decision is made on the server rather than trusted from the client. The decision should be based on stable policy inputs such as identity, tenant, object ownership, transaction state, and risk signals. It should not rely on UI visibility, hidden fields, or unpredictable application behaviour.

• Test the same action as different users, tenants, and privilege levels.
• Check whether direct object references are bound to server-side ownership rules.
• Confirm that failed authorization returns no meaningful data, not just a different status code.
• Validate that writes, deletes, and exports are protected, not only reads.

For broader control mapping, the NIST Cybersecurity Framework 2.0 and OWASP guidance both support the principle that security outcomes depend on enforcing policy at the point of decision, not after the fact. Where API ecosystems are involved, the practical question becomes whether the service independently verifies the requestor’s authority for each object and action. These controls tend to break down when teams centralize authentication but leave authorization scattered across microservices, because policy drift creates inconsistent decisions.

Common Variations and Edge Cases

Tighter authorization often increases implementation overhead, requiring organisations to balance stronger policy enforcement against developer speed and legacy integration constraints. The basic principle is simple, but the real-world edges are not. Some systems intentionally permit a request to “succeed” in a limited sense, such as returning a generic response to prevent enumeration or allowing asynchronous submission while a later workflow stage performs the actual approval. Best practice is evolving here, and there is no universal standard for every user experience pattern.

Edge cases matter most in multi-tenant platforms, delegated administration, and agent-mediated workflows. A request may be valid for an automation identity, but not for the human operator who initiated it. Likewise, service accounts, API keys, and other OWASP guidance for modern application risk are relevant when object access is driven by non-human actors with broad permissions. The key is to separate transport success from policy success.

In some environments, a “successful” response is acceptable only if the outcome is intentionally designed, audited, and reversible. That is especially important for admin consoles, bulk operations, and approval chains, where partial success can hide privilege escalation or unauthorized disclosure. Current guidance suggests treating every object-level decision as a policy event, not just an application response, and logging enough context to prove why access was granted or denied.

Related resources from NHI Mgmt Group

• What is the difference between network trust and request-level identity trust?
• What is the difference between access request automation and access governance?
• What is the difference between birthright access and request-based access?
• What is the difference between SAML request signing and response encryption?