Why is sign-in not enough to control data access in shared apps?

Why sign-in and access are different problems

Sign-in answers only one question: “Who are you?” Access control answers a different one: “What can you do here?” In shared applications, those are not interchangeable. A user can be correctly authenticated and still be allowed to see only some tenants, rows, documents, or actions. If you collapse the two, every authenticated session becomes a potential overexposure path.

The practical distinction is that authentication establishes a session or identity claim, while authorisation decides whether that claim maps to a specific record, field, workflow, or privilege. In shared tables, the safest design is to enforce that decision at the data layer, not only in the application tier, so policy remains consistent even when code paths, services, or views change.

That separation is why practitioners often rely on Authorisation Models Guide and the underlying database or policy engine pattern rather than trusting sign-in alone. Shared apps usually need a rule that evaluates each request against tenant, role, attribute, or relationship context before any row is returned or updated.

Why shared data needs row-level or policy-enforced decisions

Shared applications make the problem visible because many users are legitimate, but not equally entitled. One authenticated user may belong to multiple teams, one support operator may need read-only access, and one admin may need limited escalation. Without a separate authorisation layer, the application tends to grow special cases, and those exceptions become the source of accidental data leakage.

Database-enforced policies are useful because they sit closer to the protected data and reduce dependence on every caller doing the right thing. If the application misroutes a query, misses a filter, or reuses a code path for a different tenant, the database can still reject the row or operation. That makes the control resilient to application drift, refactors, and integration sprawl.

This is also where access governance matters. IAM and IGA Basics frames the broader lifecycle problem, while the authorisation decision itself still has to be enforced where the data is consumed. For teams managing multiple roles, entitlements, or tenant memberships, policy should be explicit enough that access can be reviewed and changed without rewriting every feature path.

What breaks when you rely on application code alone

Application-only checks fail in predictable ways. Developers forget a filter in one endpoint, a background job bypasses the usual service layer, an export path returns too much, or a new feature reuses a query that was safe only for one tenant. Once those gaps exist, sign-in still works perfectly, which makes the exposure harder to spot because the problem is not identity proof but entitlement enforcement.

The same issue appears with broader trust and delegation patterns. For example, if a token or session is accepted too broadly, the application may authenticate the caller but still fail to constrain the scope of the data behind it. Shared systems therefore need least-privilege access decisions that are consistent across read, write, export, search, and admin operations.

Where the application surface is exposed through APIs, the failure often becomes an authorisation flaw rather than a login flaw. The current OWASP Top 10 and more specific authorisation guidance both emphasise that broken access control is one of the most common ways authenticated users end up seeing data they should never reach.

Risk and Threat Considerations

When sign-in is treated as sufficient, the main risk is silent overexposure. Attackers do not need to bypass authentication if they can log in normally and then request records, tenants, or functions that were never meant for their session. In shared apps, that can turn a routine account into a data-exfiltration path or a privilege-escalation path.

Failure mechanism: The application authenticates the user but fails to make a per-object, per-row, or per-action authorisation decision close enough to the data, so a valid session can traverse into records outside its intended scope.

Impact: The result can be cross-tenant data leakage, unauthorised updates, audit noise that hides the root cause, and repeated exposure whenever a new code path is added without the same policy logic.

Practitioner Guidance

What to verify: Verify that every shared-data path applies an explicit authorisation check for the specific object, row, tenant, or action, not just for the login event. If the same user can reach different datasets through search, export, API, or batch flows, each path needs the same policy outcome.

Decision rule: If the data is shared across users, teams, tenants, or organisations, treat database- or policy-enforced authorisation as the default control and use application checks as a supplement, not the source of truth.

Common mistake: Teams often test only the “happy path” after sign-in and assume session validity implies data validity. That assumption fails as soon as a query is reused, a feature is refactored, or an integration bypasses the original UI.

Practitioner takeaway: Sign-in proves a person or system is known; authorisation proves that same identity is allowed to touch this specific data. In shared apps, the second control must be explicit, durable, and enforced where the data lives.

Related resources from NHI Mgmt Group

• How should security teams implement mandatory access control in environments with shared systems and sensitive data?
• How should security teams implement access control in retrieval augmented generation apps that handle sensitive user data?
• How should data owners control access when personal data must be shared with internal teams or external parties?
• Why do ephemeral credentials still leave risk in machine access models?