TL;DR: Authentication alone does not prevent data exposure, according to Dashlane's analysis, as the McHire case reached roughly 64 million records through a default credential and missing object-level checks. The real control gap is authorization discipline: access must be evaluated on every request, not assumed once a session starts.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Dashlane's blog post: Authentication and authorization are separate control layers, and the McHire example shows how a valid login can still expose massive data through broken object-level access checks.
Why it matters: IAM and application-security teams need to treat login success as only the start of control validation, because object-level authorization failures can turn one compromised account into broad data exposure.
Context
Authentication establishes that a requester has proven an identity claim, but it does not decide whether that identity may touch a specific record or action. In modern systems, the dangerous gap appears after login, when the application trusts the session instead of re-evaluating access against the object being requested.
That gap is especially visible in systems that mix human users, delegated access, and API-driven workflows. Once the application stops checking ownership or scope per request, a single valid account can become a general-purpose key to data that should have remained segregated.
Key questions
Q: What signs suggest an application has broken object-level authorization?
A: Broken object-level authorisation is usually visible when users can change an object identifier in a URL, API request or form and then read, edit or delete someone else’s record. Common signs include predictable IDs, missing server-side access checks, and responses that differ only by object number. Testing should confirm each request is authorised against the authenticated user’s rights.
Q: Why can a valid login still lead to major data exposure?
A: A valid login can still expose major data when the application authenticates the user but fails to enforce object-level authorisation on each record. The session is real, yet the server trusts the object reference instead of checking whether that user may access that file, account or document. This is a common cause of overexposure in APIs and web apps.
Q: What is the difference between ABAC and RBAC for access governance?
A: RBAC assigns access through fixed roles, while ABAC decides access from attributes and policy conditions at request time. RBAC is easier to understand but tends to accumulate role bloat. ABAC can be more precise, but only if attribute quality, policy design, and enforcement are consistent across systems.
Q: How should teams test for insecure direct object reference flaws?
A: Teams should test insecure direct object reference flaws by trying sequential, guessed or copied resource identifiers in URLs, API calls and form fields, then checking whether access controls block the request. The test should cover read, update and delete actions, plus indirect references hidden in JSON or headers. Server-side authorisation must be verified on every object access.
Technical breakdown
Why object-level authorization fails after login
Authentication answers a single question: is this request tied to a verified identity? Authorization answers a different one: is that identity allowed to access this specific object right now? When applications validate the user once at session start and then skip per-request checks, they create an Insecure Direct Object Reference pattern. The failure is not that login is weak, but that object identity and access scope are never tied together on each request. That leaves endpoint logic to decide by reference alone, which is exactly where data exposure begins. See the Authorisation Models Guide.
Practical implication: Move access decisions to the object boundary and test every endpoint for broken object reference handling.
How RBAC and ABAC differ in access enforcement
Role-based access control assigns permissions to roles, while attribute-based access control computes access from contextual attributes such as object ownership, device state, time, or location. RBAC is often easier to operate, but it only works when the role check is applied to the specific resource being requested. ABAC is more expressive when access needs to vary by object or context, which is why it is often better suited to fine-grained enforcement in systems that expose many records through one interface.
Practical implication: Choose the model that matches the granularity of the protected object, then verify that the policy is enforced at request time rather than at login.
Why zero-knowledge architecture changes the exposure model
A zero-knowledge design separates server-side authentication from local decryption, so the service can confirm account access without holding the material needed to read vault contents. That changes the breach math: a flaw in access control may still expose ciphertext, but it does not automatically expose plaintext. The architecture narrows what a compromised server-side permission can reveal, while still requiring careful authorization for requests that retrieve encrypted material or sharing metadata. The main value is that one missing authorization check is less likely to become universal data disclosure.
Practical implication: Use zero-knowledge design to reduce what a server-side access failure can reveal, then validate that sharing and retrieval checks still apply per object.
Threat narrative
Attacker objective: The objective was to prove that a weak login combined with missing object-level authorization could expose applicant records at scale.
- Entry began with a default credential on a test account, which gave the researchers a valid login without any password guessing or exploitation chain.
- Credential access was not the limiting factor after login, because the account itself had enough reach to call an API that returned applicant records by identifier.
- Escalation occurred through repeated object ID changes, which exposed records outside the intended scope because the backend never checked relationship or ownership.
- Impact was large-scale applicant data exposure, with names, emails, phone numbers, addresses, and chat transcripts retrievable one record at a time.
Breaches seen in the wild
- McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authentication and authorization are separate governance problems, not sequential synonyms. Organisations often treat successful login as proof of access, but that assumption collapses the moment a request targets a specific object. The McHire case shows why identity proof and object entitlement must be governed independently. Practitioners should audit access logic for that boundary, not assume a strong login layer covers the rest.
Object-level enforcement is the real control surface. The decisive failure here was not that the account existed, but that each request was allowed to resolve any applicant record without checking relationship or scope. That is a classic broken-access-control condition, and it persists wherever developers trust session state more than resource-level policy. The implication is that access governance must be measured at the endpoint, not at sign-in.
RBAC only works when it is evaluated per request. A role model can look sound on paper and still fail operationally if the application treats role assignment as a one-time event. The post's lesson is not that roles are insufficient, but that they become meaningless when the system stops asking whether the current object falls inside the role's scope. Practitioners should test for that drift explicitly.
Zero-knowledge design reduces blast radius, but it does not replace authorization discipline. Separating decryption from account access narrows what a server can reveal, yet it still depends on correct request-time access checks for sharing and retrieval paths. That distinction matters across password managers, enterprise vaults, and any system where authentication, authorization, and data readability are decoupled. Teams should treat cryptographic separation as containment, not as a substitute for policy enforcement.
What this signals
Access control has to move from session time to request time. Identity programmes that validate a user once and then trust the session are effectively blind to object-level risk. The stronger pattern is continuous entitlement evaluation at the point where the record, action, or resource is requested, because that is where ownership can be misapplied.
Hybrid identity stacks are now exposed to the same design flaw across humans, services, and delegated access. Once a platform supports multiple identities against the same API surface, a single missing ownership check can affect far more than a human web login. The practical signal is that teams should review every data-returning endpoint as a governance control, not just as an application feature.
For practitioners
- Audit every object lookup for per-request authorization Map each endpoint that returns records or actions to the exact policy check it performs at request time. Any path that trusts a session once and then serves arbitrary object IDs should be treated as a broken access control candidate. See the Authorisation Models Guide.
- Eliminate default and test-account credentials Inventory non-production and dormant accounts, assign ownership, and remove any password or token that can still open a login path. Test credentials should expire or be disabled before they can become a live entry point. See the Test and Synthetic Accounts Governance Guide.
- Test for IDOR with low-privilege sessions During application testing, modify object IDs, resource references, and role-bound actions while authenticated as the least privileged account. Confirm that every request fails closed unless the requester is entitled to that exact object.
- Separate authentication from data readability Where vaults or encrypted stores are involved, ensure that proving account access is not enough to decrypt sensitive content. Keep decryption keys bound to the appropriate user or role and verify that encrypted returns are unusable without the right local material.
Key takeaways
- A strong login does not prevent data exposure if the application skips object-level authorization on each request.
- The McHire case shows how one weak test account can turn into broad record exposure when resource checks are missing.
- Teams should test for broken access control by manipulating object references, not only by verifying authentication flows.
Related NHI Mgmt Group resources: Authorisation Models Guide · OWASP Top 10 A07 Guide · Test and Synthetic Accounts Governance Guide · McHire default password flaw 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | The core failure was object-level access to applicant records through an API. |
| Recommendation — Enforce object-level authorization on every API request and deny any identifier that is not explicitly allowed. | ||
| OWASP ASVS | V8 — Authorization | The article centers on request-time authorization and broken access control in applications. |
| Recommendation — Verify that authorization checks run at the resource level for every protected action and data object. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The breach pattern shows overly broad access after authentication. |
| Recommendation — Limit each authenticated identity to the minimum resource scope needed for its task. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The gap is in permissions enforcement after identity is established. |
| Recommendation — Review and enforce entitlements at the point of access request, not only at sign-in. | ||
| CIS Controls v8 | CIS-5 — Account Management | Test and dormant accounts created the entry point in the example. |
| Recommendation — Remove or govern dormant accounts and validate that every account has an owner and purpose. | ||
Key terms
- Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
- Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
- Insecure Direct Object Reference: Insecure direct object reference is an access control flaw where an application exposes an identifier that allows callers to reach records or objects they should not be able to access. In practice, it means the system trusts the request too much and fails to verify object-level permission on each access.
- Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org