How small application design decisions around accounts, messages, passwords, and roles can create security problems before the exploit even starts.
This is the first article in my OWASP Top 10 2025 series.
After finishing my Key Web Vulnerabilities series, I wanted the next step to be broader: not only payloads and labs, but application behaviour and design decisions.
A01 Broken Access Control is a good place to start because access control looks simple on the surface:
<pre><code>Can this user do this action?
</code></pre>
But in real applications, that question appears everywhere: accounts, roles, permissions, ownership, endpoints, workflows, messages, and logs.
And sometimes the weakness starts before the final exploit.
It starts with assumptions.
<h2>A01 is not only about one broken endpoint</h2>
Broken Access Control happens when an application does not correctly enforce what a user can do.
The useful distinction is:
<pre><code>Authentication: who are you?
Authorization: what are you allowed to do?
</code></pre>
Authentication may work perfectly. The user may be logged in, the password may be correct, and the session may be valid.
But that does not answer the next question:
<pre><code>Are you allowed to access this resource or perform this action?
</code></pre>
That is where access control lives.
For this first article, I do not want to start with the final privilege escalation request yet. That comes later.
I want to start one step earlier: weak assumptions around accounts, messages, passwords, roles, and ownership.
Because A01 is not only a missing <code>if (user.isAdmin)</code> check. It is often a weak access model that was never reviewed properly.
<h2>Small details become security signals</h2>
<img src="https://media.daily.dev/image/upload/s--yKvf9cdp--/f_auto/v1782987641/ugc/content_fe641a08-714b-4f2e-b0c4-4b68c062430a?_a=BAMAMicg0" alt="96e1d949-d2b9-4298-9a51-6f27db0e57db.png">
A small message can tell an attacker something useful.
For example:
<pre><code>User not found
</code></pre>
and:
<pre><code>Password is incorrect
</code></pre>
may look like helpful UX.
But together, they reveal whether the username exists.
That may not be Broken Access Control by itself. It is closer to authentication and enumeration. But access control does not exist in isolation.
If an attacker can enumerate users, identify privileged accounts, guess weak passwords, and then test authorization boundaries, the app has made the attack easier.
A better external message might be:
<pre><code>Invalid username or password.
</code></pre>
The application can still log the detailed reason internally, but the public response should not help attackers separate valid users from invalid ones.
<h2>A message is not always just text</h2>
The visible text is only one signal.
The application may show a generic message but still leak information through HTTP status codes, response length, redirects, timing, URLs, or error IDs.
The visible text may be the same, but response code or timing may differ depending on whether the account exists.
This does not mean the app must become hostile to users. It means auth-related responses should be reviewed as security design, not only copywriting.
Sometimes a message is a side channel.
<h2>Do not make privileged accounts obvious</h2>
Another small design decision: privileged account naming.
If a public login form accepts a username and one of the important privileged users is literally:
<pre><code>admin
</code></pre>
that is not a great start.
The problem is not the word itself. The problem is predictability.
An attacker does not need to guess whether an administrator account exists. The application has already helped them choose a target.
The same applies to default accounts, old test accounts, shared support accounts, and service-like accounts.
I prefer to think about it this way:
<pre><code>admin should be a role or permission model, not an obvious public identity.
</code></pre>
A person may have an administrative role. A service may have a machine identity. A support user may have scoped permissions.
Predictable privileged usernames are a design smell, not just a password problem.
<h2>Password strength is also an application design decision</h2>
<img src="https://media.daily.dev/image/upload/s--rm1-dwX7--/f_auto/v1782987943/ugc/content_cf7948af-cfed-45c6-b9ad-1ec46f2df71c?_a=BAMAMicg0" alt="5a9d3226-043b-4da3-98d4-ccefbc47e313.png">
In AppSec, I would not describe this only as “how long does it take to crack a password?”, because for a normal web login the attack is online.
The attacker is not testing billions of guesses per second against a stolen hash. They are sending login attempts to the app.
So the real question becomes:
<pre><code>How many guesses does the application allow?
</code></pre>
What happens before it slows down, locks out, challenges with MFA, or alerts?
A password like:
<pre><code>summer2024
</code></pre>
looks better than <code>123456</code>, but it still follows a predictable pattern:
<pre><code>common word + year
</code></pre>
If attackers know users pick passwords like this, they can try common words with common number patterns instead of brute-forcing everything.
If the attacker tries a small pattern of 10,000 guesses, the time depends on the application controls:
<pre><code>100 guesses per minute -&gt; about 100 minutes
10 guesses per minute -&gt; about 16.6 hours
5 guesses per minute -&gt; about 33.3 hours
</code></pre>
This is not offline password cracking math.
This is online guessing math.
With proper throttling, temporary account lockout, MFA, and monitoring, even that pattern should become unrealistic, noisy, or blocked.
For example, after several failed login attempts, the application can slow the attacker down, temporarily lock the account, require an additional MFA challenge, or alert the user/security team.
The important detail is that lockout should be designed carefully. A hard permanent lockout can create a denial-of-service problem if attackers intentionally lock other users out. A better approach is usually risk-based: progressive delays, temporary lockouts, MFA challenges, and clear recovery paths.
A passphrase like:
<pre><code>Lantern-Mosaic!River-7428
</code></pre>
is longer, less predictable, and still readable. It gives the app much more room to defend against online guessing.
The point is not “add one uppercase letter and one symbol because the policy says so”. The point is to make passwords hard to guess while keeping them usable.
These are only placeholders for the article and should not be reused as real passwords.
<h2>Authentication and authorization are different, but connected</h2>
This is where the article comes back to A01.
Authentication asks:
<pre><code>Is this a valid user?
</code></pre>
Authorization asks:
<pre><code>Is this user allowed to do this?
</code></pre>
They are different controls, but bad authentication design can make access control attacks easier.
If attackers can enumerate users, identify privileged identities, guess weak passwords online, and learn too much from error messages, they get a better starting point.
A01 is not only about one missing check. It is about the whole access model surviving real users, real roles, real objects, real workflows, real mistakes, and real attackers.
<h2>Roles, permissions, and ownership need a clear model</h2>
<img src="https://media.daily.dev/image/upload/s--L4IUZIW---/f_auto/v1782988244/ugc/content_04c9984f-9dd3-48c1-80b5-3328295d3935?_a=BAMAMicg0" alt="d9d00f22-57ef-4713-8472-ebdd722f4aa8.png">
Before writing access checks, the application needs a model.
For example: who owns this record, who can view it, who can edit it, who can approve it, and who can assign roles?
Role checks and ownership checks are not the same.
A normal user may edit their own profile but not someone else’s. A manager may approve team requests but not another department’s. An admin may manage users but still not read every sensitive record.
This is where mature access control becomes more than:
<pre><code>isAdmin === true
</code></pre>
A clear model makes code review and testing easier.
An unclear model creates inconsistent checks and risky exceptions.
<h2>What should be fixed after this part?</h2>
After reviewing this first layer, I would look for fixes like:
<pre><code>Use generic authentication messages where appropriate.
Avoid revealing whether an account or privileged identity exists.
Treat admin as a role or permission set, not a predictable login.
Require strong, usable passwords and support long passphrases.
Block common or breached passwords.
Use throttling, lockout, MFA, and monitoring for online attacks.
Log detailed reasons internally, but control external responses.
Review status codes, timings, redirects, and URLs as security signals.
Define roles, permissions, and ownership before relying on access checks.
</code></pre>
The goal is not to make the application mysterious.
The goal is to avoid giving attackers unnecessary structure.
<h2>Summary</h2>
Broken Access Control often appears as a missing authorization check, but the weakness can start earlier.
Bad assumptions around messages, accounts, passwords, roles, and ownership can create a softer target before the final access control bug is tested.
This is why I wanted Part 1 to be about design.
Login messages are not the same thing as Broken Access Control. But OWASP Top 10 is not only about payloads. It is also about how applications are designed, reviewed, tested, and maintained.
In Part 2, I will move closer to the classic A01 problem: authenticated users accessing data or actions that do not belong to them.
<h2>My takeaway</h2>
The biggest shift after finishing the Key Web Vulnerabilities series is that I do not want to look only for “the vulnerable request”.
I want to look at the assumptions that make the request dangerous.
A weak message, predictable privileged account, bad password policy, or unclear role model may not be the final exploit.
But they shape the path toward it.
Access control does not start at the admin endpoint.
It starts with the way the application thinks about identity, permission, and trust.
#appsec #cybersecurity #security #authN #authZ

Przemyslaw

A deep dive into OWASP Top 10 2025 A01 Broken Access Control, focusing on the design-level assumptions that create vulnerabilities before any exploit occurs. Covers how authentication error messages can leak user existence, why predictable privileged usernames (like 'admin') are a security smell, how online password guessing differs from offline cracking and why throttling/lockout design matters, and why roles, permissions, and ownership need a clearly defined model before access checks are written. Emphasizes that access control weaknesses often begin with weak application design decisions, not just a missing authorization check.

OWASP Top 10 2025 A01, Part 1: Broken Access Control Starts With Bad Security Assumptions