OWASP Top 10 2025 – IAAA Failures

Overview

OWASP Top 10 2025 IAAA failures make a lot more sense when you stop looking at authentication, permissions, and logging as separate security topics and start looking at them as parts of the same process.

That was probably my biggest takeaway from this TryHackMe room.

When I normally look at a web application, I tend to think about things such as login forms, sessions, user roles, exposed pages, and whether one account can access something it shouldn’t. The IAAA model gives all of those observations a simple structure: Identification, Authentication, Authorization, and Accountability.

None of these concepts were completely new to me, but putting them together as one model made it easier to understand where certain OWASP vulnerabilities actually fit and, more importantly, what question I should be asking when testing an application.

What Is the IAAA Model?

IAAA describes four stages of how an application deals with users and their actions:

• Identification — Who are you claiming to be?
• Authentication — Can you prove it?
• Authorization — What are you allowed to do?
• Accountability — Can the application record what you did?

I like thinking about it as a sequence rather than four unrelated definitions.

A user first identifies themselves, usually with something simple such as a username or email address. The application then authenticates that identity using a password, MFA, certificate, security key, or another mechanism. Once the user is authenticated, authorization determines what resources and actions that account should actually have access to.

Finally, accountability creates a record of those actions.

That last part can be easy to overlook when learning offensive security because it doesn’t necessarily help you gain access to anything. From a defensive perspective, though, it is critical. If someone logs in, changes permissions, downloads sensitive information, or repeatedly attempts unauthorized actions, the organization needs enough logging to reconstruct what happened.

Identification: Who Are You?

Identification is the simplest part of the model. It is just the user telling the application who they are.

For example:

username: bwright

or:

email: user@example.com

At this stage, the application hasn’t proven anything. Anyone can type another person’s username into a login form.

This distinction sounds obvious, but it becomes important when looking at badly designed applications. A username, email address, account number, or other identifier should never be treated as proof that the person submitting it actually owns that identity.

Identification starts the process. Authentication establishes trust.

Authentication: Can You Prove It?

Authentication is where the application verifies the claimed identity.

The most familiar example is a username and password, although modern applications may also use:

• Multi-factor authentication
• One-time codes
• Hardware security keys
• Certificates
• Biometrics
• Authentication applications
• Federated identity providers

This is where weak passwords, insecure password reset processes, poor session handling, default credentials, and similar problems begin to matter.

One thing I keep coming back to in security is that a login page itself does not make an application secure. The strength of the authentication process depends on everything surrounding it: how credentials are stored, how sessions are issued, how passwords can be reset, how long sessions remain valid, and what happens when authentication repeatedly fails.

Authorization: Just Because You Logged In Doesn’t Mean You Belong There

Authorization is probably the part of IAAA that becomes the most interesting during web application testing.

A user may be completely legitimate and properly authenticated but still gain access to something they should never be able to see.

Imagine an application containing a request such as:

/account/1001

If changing that value to:

/account/1002

allows one customer to view another customer’s information, authentication technically worked. The application knew who the user was.

Authorization failed.

This is why simply finding a login page and confirming that users must authenticate doesn’t tell you very much about the application’s actual security.

Once I have access to an application, some of the questions I want to ask are:

• Can a normal user access administrative functionality?
• Can one user retrieve another user’s records?
• Does changing an object ID expose another resource?
• Are permission checks performed by the server?
• Does hiding a button in the interface actually prevent the request?
• Can the application be forced to perform an action outside the user’s assigned role?

These are the kinds of failures that connect directly with Broken Access Control.

Accountability: What Happens After the Request?

Accountability is the defensive side of the model.

Applications should create enough useful logging to answer basic investigative questions after something suspicious happens.

For example:

• Which account performed the action?
• When did it happen?
• What system or IP address was involved?
• Was the authentication attempt successful?
• What resource was accessed?
• Were privileges changed?
• Were repeated failures recorded?
• Did anything alert the security team?

This is especially relevant to me because I spend a lot of time working with logging, monitoring, and SIEM systems.

A vulnerability is one problem. Having that vulnerability exploited without producing useful telemetry creates a second problem.

If a security team cannot reconstruct what occurred after an incident, response becomes significantly harder.

How This Connects to the OWASP Top 10

The IAAA model gives me a useful way to organize several common web application weaknesses.

Broken Access Control

Broken access control is primarily an authorization problem.

The application may authenticate the user correctly but fail to enforce what that user should be permitted to access.

Examples can include:

• Missing server-side permission checks
• Accessing another user’s records
• IDOR-style weaknesses
• Horizontal privilege escalation
• Vertical privilege escalation
• Normal users reaching administrative functions

The important lesson here is that access control has to be enforced by the application itself. Hiding a menu item or disabling a button in the browser is not sufficient.

Identification and Authentication Failures

These weaknesses affect the application’s ability to reliably determine who is using it.

They can involve problems such as:

• Weak authentication mechanisms
• Poor password policies
• Default credentials
• Improper session handling
• Weak account recovery
• Missing or poorly implemented MFA

From a testing perspective, this means the login page is only the beginning. Password resets, session cookies, logout behavior, account recovery, and privilege transitions are all part of the authentication process.

Security Logging and Monitoring Failures

This is where accountability becomes important.

An organization may have reasonably strong authentication and authorization controls but still struggle during an incident because important events were never logged or monitored.

Problems might include:

• Important authentication events not being recorded
• Administrative actions missing from audit logs
• Failed login attempts generating no alerts
• Logs being retained for too short a period
• Security events being generated but never reviewed
• Insufficient information being captured for an investigation

Logging doesn’t stop every attack, but it can determine whether an attack is detected quickly or discovered much later.

How I Would Use IAAA During a Web Assessment

The part of this room that I found most useful was turning the model into questions I can actually use.

Instead of simply thinking, “I’m testing authentication,” I can break the application down like this:

Area	Question I Ask
Identification	How does the application determine which identity a user is claiming?
Authentication	How does that user prove the identity is theirs?
Authorization	What prevents that user from accessing someone else’s resources?
Accountability	What evidence is created when the user performs an action?

That makes the model useful beyond memorizing terminology.

If I change a request parameter and suddenly see another user’s information, I know I am looking at authorization.

If password resets can be abused, I am looking at authentication.

If a sensitive administrative action generates no meaningful audit trail, I am looking at accountability.

The model becomes a troubleshooting framework for security.

Why This Matters Outside a TryHackMe Room

These failures are not limited to intentionally vulnerable labs.

Most real applications have multiple user types, permissions, sessions, APIs, administrative functions, and sensitive resources. Every one of those areas depends on the application correctly answering the same basic questions:

Who is this user?

Did they prove their identity?

Should they be allowed to perform this action?

Will we know that they performed it?

A mistake anywhere in that chain can become a security vulnerability.

That is also why IAAA works equally well from both an offensive and defensive perspective. A penetration tester can use it to look for weaknesses, while a defender can use the same model to decide where controls, monitoring, and audit trails need to exist.

Lessons Learned

The biggest lesson I took from this room is that authentication should never be treated as the end of the security process.

Successfully logging someone into an application answers only one question. The application still needs to enforce what that person is allowed to do, validate sensitive actions on the server, and create enough logging to identify misuse later.

The IAAA model also gives me a simple way to classify what I am seeing during testing. Rather than immediately trying to attach a vulnerability name to everything, I can first determine which security control failed.

That often makes the actual vulnerability easier to understand.

Key Takeaways

The IAAA model breaks identity and access security into four useful questions:

• Identification: Who does the user claim to be?
• Authentication: How do they prove that identity?
• Authorization: What is that identity permitted to access?
• Accountability: Can their actions be reconstructed afterward?

For me, the value isn’t really in memorizing those four definitions. It is having another framework I can use when looking at an application.

Authentication gets the user through the door. Authorization determines which rooms they can enter. Accountability tells us where they went afterward.

Skills Practiced

• Understanding identity and access management concepts
• Recognizing authentication weaknesses
• Identifying authorization failures
• Relating access control problems to the OWASP Top 10
• Understanding the role of application logging
• Viewing web security from both offensive and defensive perspectives

Defensive Considerations

Applications should enforce authorization on the server for every sensitive request, use strong authentication and session-management practices, and maintain useful audit logs for important security events.

Security teams should also monitor authentication failures, privilege changes, administrative activity, and unusual access patterns so that an individual control failure does not automatically become an undetected incident.