Why do valid sessions still lead to unauthorized access when access control is broken?

A valid session only proves who the caller is. It does not prove the caller may read, update, delete, or invoke that resource. Broken access control appears when the application skips the authorization check or applies it inconsistently, so ordinary authenticated requests cross a boundary they were never allowed to cross.

Why This Matters for Security Teams

Valid sessions are not a substitute for authorisation. When access control is broken, an authenticated caller can still cross object, function, or tenant boundaries because the application trusts the session but fails to re-check what that session may do. That gap is exactly how broken object level and function level authorisation become breach paths, even when login controls are strong.

This pattern is especially dangerous for non-human identities because service accounts, API keys, and automation often carry broad entitlements and run continuously. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges in the Ultimate Guide to NHIs, which turns a single missed check into an easy privilege boundary failure. OWASP also treats broken access control as a top class of application weakness in the OWASP Non-Human Identity Top 10.

In practice, many security teams discover the flaw only after a routine authenticated request has already accessed records, invoked admin functions, or pivoted into a different tenant.

How It Works in Practice

A session proves identity, usually through a cookie, token, or signed assertion. Authorisation is a separate decision that must happen on every sensitive request. If the application checks only once at login, or assumes a valid session implies universal access, the caller can reuse that session to perform actions it was never meant to perform. That is why standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both emphasise least privilege, access enforcement, and consistent verification.

For NHIs, the problem is usually worse because the caller is automated and may touch many resources quickly. A secure pattern is to bind every request to the workload identity, then evaluate policy at runtime with context such as tenant, resource owner, action, time, and environment. Current guidance suggests using short-lived credentials, per-task scoping, and explicit deny-by-default rules so the session is only valid for the narrow action it was issued to perform. The NHIMG Ultimate Guide to NHIs — Key Challenges and Risks highlights how long-lived secrets and broad entitlements magnify this failure mode.

• Authenticate the caller, then authorise each object or function separately.
• Use workload identity to prove what the service or agent is, not just that it has a session.
• Issue just-in-time access for a single task or transaction when possible.
• Log both the request and the authorisation decision so failures are traceable.

These controls tend to break down in legacy applications and shared middleware because permissions are cached, checks are centralised too late in the request path, or ownership data is missing at the object layer.

Common Variations and Edge Cases

Tighter access control often increases engineering overhead, requiring teams to balance safety against latency, code complexity, and operational friction. That tradeoff is real, especially in systems with high request volume or delegated admin workflows.

Some environments blur the line between session validity and authorisation. For example, a privileged service account may legitimately hold a session and still be blocked from certain records, while a human user may pass authentication but fail row-level checks. Guidance is evolving on how far runtime policy engines should go, but the consensus is clear that static role checks alone are not enough for dynamic workloads. The NHIMG 52 NHI Breaches Analysis and the Microsoft SAS Key Breach both show how valid credentials can still be misused when scope is too broad or enforcement is inconsistent.

Edge cases also appear in federated systems, cached authorisation decisions, and admin consoles that trust upstream claims without re-evaluating access. In those cases, the safest approach is to treat every privilege-bearing action as a fresh decision point, not as a consequence of a previously valid session.

Related resources from NHI Mgmt Group

• When should teams move from point-in-time governance to continuous access control?
• What breaks when access reviews and segregation of duties are still handled manually at enterprise scale?
• How should organisations implement policy-based access control in identity-centric security programmes?
• Why do cloud password platforms still create concern for organisations with strict access governance?