One of the biggest lessons in building software for businesses is that security is not only about stopping people from logging in without permission. A system can have a secure login process and still expose sensitive customer information if it does not properly control what users are allowed to access after they have logged in.
One example of this is a security vulnerability known as IDOR (Insecure Direct Object Reference).
In simple terms, IDOR happens when an application allows a user to directly request information using an identifier, but the system fails to confirm that the user is actually allowed to access that information.
An identifier is simply a piece of information used to identify a specific record in a system. It could be a customer number, account number, order number, phone number, or transaction reference.
For example, imagine a banking application where a customer views their account balance through a request that contains their account identifier. If the system only checks that the person is logged in but does not verify that the account identifier belongs to that person, a malicious user could change the identifier and potentially view another customer's balance or transaction history.
The dangerous part is that the attacker does not necessarily need to break into the system. They may already have a valid account and a valid login. The weakness comes from the application failing to verify whether that user is allowed to access the specific information they requested.
For businesses handling customer information, the impact can be significant. A similar issue in a financial platform could expose customer balances, transaction history, payment records, or other sensitive information. In systems where customers can make purchases or transfer money, unauthorized access could also create financial risks.
This is why there is an important difference between authentication and authorization.
Authentication answers the question: "Who are you?"
For example, a customer enters their phone number and PIN, and the system confirms their identity.
Authorization answers a different question: "Are you allowed to access this information?"
A customer may successfully prove who they are, but that does not mean they should be able to access every customer's information.
While designing systems that handle customer transactions, one approach is to create a secure digital identity after a customer successfully logs in. This identity is stored inside a secure token that the customer presents with every request they make to the system.
A token is simply a digital proof that tells the system, "This request comes from an authenticated customer." In many modern applications, this is implemented using technologies such as JWT (JSON Web Token), but the important concept is not the technology itself. The important concept is that every request must carry a verified identity.
For example, consider a system where customers are identified by their phone numbers and each phone number is protected by a PIN.
During login, the customer provides their phone number and PIN. The system validates that the PIN matches the account. Only after successful verification does the system generate a secure token containing the customer's verified identifier, in this case their phone number.
From that moment, every request made by the customer includes this token. Before returning any account information, the system compares the identity inside the token with the customer information being requested.
If the customer requests information belonging to a different phone number, the system rejects the request.
This prevents a situation where someone creates a valid account, obtains a valid token, and then attempts to change the identifier in a request to access another customer's information. The request may be authenticated, but it is not authorized.
t is important to understand that preventing IDOR is not simply a matter of using secure tokens. Modern frameworks can make authentication much easier by providing a reliable way to identify the user making a request. However, the responsibility of checking whether that user is allowed to access a specific resource still belongs to the application.
A system can have a perfectly implemented login process, secure tokens, and a reliable way of identifying users, but still be vulnerable if the application code does not perform the correct authorization checks.
For example, a controller that receives a request for an order, transaction, or account record must not only ask, "Does this record exist?" It must also ask, "Does this record belong to the user making this request?"
A careless implementation might retrieve a record directly using an identifier provided in the request and return it to the user. While the user may be properly authenticated, the system has failed to verify whether they are authorized to access that specific piece of information.
This is why security requires both authentication and authorization. Authentication establishes identity. Authorization protects access. Both are required to build systems that customers and businesses can trust.
The key lesson is that secure software does not only ask, "Is this person logged in?" It also asks, "Does this person have permission to access this exact piece of information?"
For businesses, this distinction is critical. Customer trust is built on the assumption that personal information, financial data, and transaction records are protected. A single missing authorization check can become a serious privacy violation and expose an organization to financial losses, regulatory consequences, and reputational damage.
Security is not something added after software is built. It is part of how software should be designed from the beginning.
