Topic starter
06/11/2026 6:39 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Dashlane: “Authentication Vs. Authorization: Who You Are Vs. What You Can Touch”.
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.
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.
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.
Practitioner guidance
- 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.
- 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 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.
Bottom line: A strong login does not prevent data exposure if the application skips object-level authorization on each request.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Authorization failures expose data even after login is solved