5 Authorization Mistakes I Keep Finding During Manual Application Security Testing

Whoami

I'm Mohammed Khaleel Ul Hasan — an Application Security enthusiast with a passion for understanding how web applications work, where they break, and how they can be built more securely. I enjoy exploring authorization, API security, business logic, and the subtle flaws that automated scanners often miss. Sometimes that curiosity uncovers interesting security issues. Other times, it simply teaches me something new. Either way, every assessment is an opportunity to learn.

Introduction

If someone asked me which vulnerability I encounter the most during application security assessments, my answer probably wouldn't be SQL Injection or Cross-Site Scripting.

It would be Broken Access Control.

Not because developers don't care about security.

But because authorization is one of the hardest security problems to implement correctly.

Every feature in an application introduces new questions:

• Who should be able to see this?
• Who should be able to edit it?
• Who should approve it?
• Who should even know it exists?

After spending weeks performing manual application security assessments, I realized something interesting.

I wasn't finding the exact same vulnerabilities.

I was finding the same authorization mistakes repeated in different ways.

Here are the five patterns I've encountered most often — and why every developer and Application Security engineer should pay attention to them.

1. Trusting the UI Instead of the Backend

One of the most common assumptions in web applications is:

"The user can't see the button, so they're not able to perform the action."

Unfortunately…

Attackers don't interact with your application the same way normal users do.

They intercept requests.

They modify parameters.

They replay API calls.

They completely ignore the user interface.

If the backend doesn't validate every request independently, hiding functionality in the UI provides little security.

The frontend should improve usability.

The backend should enforce security.

2. Checking the Role… but Forgetting the Resource

Many authorization systems stop after verifying the user's role.

Role = Pentester
✅ Allow

Role = Pentester
✅ Allow

But that's only half of the authorization decision.

The real question is:

Should this particular user be allowed to access this particular resource?

Consider two users with the same role.

Both are Pentesters.

Should they automatically have access to each other's engagements?

Probably not.

Modern applications need more than Role-Based Access Control (RBAC).

They also need ownership, assignment, or tenant validation.

Authorization should answer both questions:

• Who are you?
• What are you allowed to access?

3. Assuming Every Workflow Is Protected

Modern applications rely heavily on workflows.

Reports move through approval stages.

Findings change status.

Retests are requested.

Remediations are verified.

Each state transition represents a security decision.

During testing, one of the first questions I ask is:

What happens if I bypass the UI and send the request directly?

If the backend doesn't validate whether the current user is allowed to perform that transition, workflows can quickly become inconsistent — or worse, exploitable.

Authorization isn't just about pages and APIs.

It's about protecting the application's business logic.

4. Exposing More Information Than Necessary

Not every security issue involves sensitive data like passwords or tokens.

Sometimes applications expose information that seems harmless:

• Internal workflow states
• Resource names
• User roles
• Project or engagement names
• Report statuses
• Assignment details

Individually, these may appear insignificant.

Together, they provide valuable reconnaissance that helps an attacker better understand the application's internal structure.

One principle I try to remember is simple:

If a user doesn't need to know something, the application probably shouldn't expose it.

5. Thinking the Fix Is Finished

One of the biggest lessons I've learned is that fixing a vulnerability doesn't always mean the problem is solved.

Sometimes the backend is secured…

But the UI still exposes unauthorized actions.

Sometimes permissions are corrected…

But dropdown filters still reveal resources outside the user's scope.

Sometimes one endpoint is fixed…

While another endpoint performing the same operation remains vulnerable.

This is why regression testing is just as important as the original assessment.

Security fixes should improve the application — not introduce new inconsistencies.

My Biggest Takeaway

When I first started learning Application Security, I thought authorization testing meant comparing different roles.

Admin vs User.

Manager vs Employee.

Client vs Administrator.

Today, I approach it differently.

I create multiple users.

I test ownership.

I test assignments.

I test workflows.

I test APIs directly.

Most importantly…

I stop asking:

"Can this role perform this action?"

And instead ask:

"Should this specific user be allowed to perform this specific action on this specific resource?"

That single question has helped me uncover far more meaningful authorization issues than simply comparing permissions between different roles.

Final Thoughts

Broken Access Control continues to rank as one of the most critical risks in modern web applications — not because developers ignore security, but because authorization is incredibly nuanced.

Every new feature, every API endpoint, every workflow, and every role introduces another authorization decision.

For developers, the challenge is designing authorization that consistently enforces both role and ownership.

For Application Security engineers, the challenge is thinking beyond the UI and asking the questions attackers will inevitably ask.

The next time you're testing an application, don't stop after comparing Admin vs User.

Create two users with the same role.

You might be surprised by what you discover.

What authorization mistakes have you encountered during your assessments or development work? I'd love to hear your thoughts in the comments.

If you enjoyed this article, consider following me on Medium and connecting with me on LinkedIn. I'll be sharing more practical insights from my journey in Application Security, API Security, and Secure SDLC.

✨ Thanks for reading my story! Clap 👏 if you enjoyed it, and follow for more of my bug hunting adventures.

Got questions or your own close-call stories? Drop them in the comments or hit me up on LinkedIn!