OWASP and live bugs

Threat modelling asks what could go wrong before you build.

OWASP helps you recognise what has already gone wrong in live applications.

A bug report might say:

A signed-in customer can change the id in /orders/123 and read someone else's order.

That is a real bug, but it also has a shared name: broken access control. In the OWASP Top 10, that is A01.

What OWASP is

OWASP is the Open Worldwide Application Security Project, a nonprofit community that publishes free application security guidance.

The best-known OWASP project is the OWASP Top 10. It is a list of common and serious web application security risk categories.

Think of it as a map, not a checklist.

The current released list is 2025

OWASP says the most current released version is the OWASP Top 10 2025.

The category names and numbers below use that edition.

The list gives developers a shared language. Instead of saying "the app lets users see records they should not see", a team can say "this is broken access control."

The short name doesn't fix the bug. It helps people find the right conversation faster.

JunoWhat OWASP is OWASP is like a shared map of common app security trouble.

The Top 10 doesn't prove an app is safe. It helps you recognise the kinds of mistakes developers keep finding in real web apps.

JunoWhat OWASP is Use the Top 10 as vocabulary in reviews and bug reports. "A01 broken access control" is shorter than re-explaining that a user can reach data or actions outside their permission.

The practical win is routing. Once the category is named, you know which code area to inspect, which tests to write and which later handbook chapter will go deeper.

JunoWhat OWASP is OWASP started in 2001, back when "web application security" was still earning its own shelf. The Top 10 became popular because ten buckets are easier to carry into a meeting than a wall of individual weaknesses.

That popularity is also the trap. "We handle the Top 10" isn't proof of safety, it's a statement that you looked at common ground.

The interesting failures are still the ones hiding in your product's specific decisions, where no global list knows the odd little bargain you made with reality.

The 2025 categories

You don't need to memorise the list. Read each category as a question you can ask about code.

Code	Category	Developer question
A01	Broken Access Control	Can someone reach data or actions they should not?
A02	Security Misconfiguration	Did an unsafe setting ship?
A03	Software Supply Chain Failures	Can you trust the packages, tools and build path?
A04	Cryptographic Failures	Is private data protected when stored or sent?
A05	Injection	Can user text become an instruction?
A06	Insecure Design	Was the unsafe choice made before code existed?
A07	Authentication Failures	Can the app reliably tell who someone is?
A08	Software or Data Integrity Failures	Was code or data changed before it reached you?
A09	Security Logging and Alerting Failures	Would anyone notice the attack?
A10	Mishandling of Exceptional Conditions	Does an error leave the app unsafe?

The order matters less than the habit. Pick a live bug, name the category, then explain the impact in plain language.

For the order-id bug, the category is A01 Broken Access Control. The impact is: any signed-in customer can read another customer's order history and delivery address.

OWASP gives the bug a name; your report still has to explain the harm.

JunoThe 2025 categories Each OWASP category is a bucket for many smaller bugs.

Start with the plain question. Can someone read something private? Change something they should not? Make the app stop answering? The category name comes after you understand the harm.

JunoThe 2025 categories Name the category, then write the user-facing outcome. A01 is useful, but "any signed-in customer can read another customer's address" is what helps a team prioritise.

That keeps OWASP from becoming label collecting. The category routes the work. The impact explains why the work matters.

JunoThe 2025 categories The 2025 list changed because software changed. Supply chain failures moved into the main list, exceptional-condition handling became its own category, and server-side request forgery rolled into broken access control.

Read movement between editions carefully. A category can rise because it got broader, because contributors changed, or because tooling got better at finding it. A rank is a signal, not a weather report from the entire industry. Useful, yes. Omniscient, no, which is probably for the best.

OWASP after STRIDE

STRIDE and OWASP are useful at different moments.

Tool	Best time	Question
STRIDE	Before and during design	What could go wrong?
OWASP Top 10	During review, testing and triage	What kind of bug is this?

In a planning session, STRIDE helps you spot that QuickBite needs server-side price calculation.

In a live bug report, OWASP helps you say the browser-controlled price is an integrity problem and likely belongs under injection, access control or insecure design depending on how it works.

The tools fit together:

1. STRIDE predicts possible failures.
2. The app gets built and tested.
3. OWASP helps name the bugs that appear.
4. Bug triage turns the finding into priority and next action.

JunoOWASP after STRIDE STRIDE is for asking what could go wrong before the feature ships. OWASP is for recognising the kind of bug you're looking at once something has gone wrong.

You don't have to choose one. They answer different questions.

JunoOWASP after STRIDE Use STRIDE in planning and OWASP in review or triage. That gives you a clean timeline: predict, build, recognise, prioritise.

If a finding lands with only an OWASP label, ask for the reproduction and the impact. The label is a pointer, not the report.

JunoOWASP after STRIDE STRIDE is design pressure. OWASP is recognition pressure. Triage is delivery pressure. Mixing them is how teams end up with a threat model that reads like a vulnerability report and a vulnerability report that reads like a horoscope.

Keep the jobs separate. Before code exists, ask what could go wrong. Once a bug exists, name the class, prove the behaviour and state the harm. Then decide what happens next before the meeting becomes a group reading of everyone's anxiety.

Try it

Five bugs from a real backlog. Name the OWASP 2025 category for each, then write the impact in a sentence a non-engineer would understand.

1. A signed-in customer changes the id in /orders/1042 and sees another customer's delivery address.
2. The admin panel ships with the default password still set.
3. A search box puts the typed text straight into a database query.
4. Failed logins are never recorded anywhere.
5. A dependency was updated last week by a maintainer account that had been taken over.

Compare your answers

#	Category	Impact in plain words
1	A01 Broken Access Control	Any signed-in customer can read another customer's order history and delivery address
2	A02 Security Misconfiguration	Anyone who knows the default password has full administrative control
3	A05 Injection	A visitor can make the database run commands the app never intended, reading or deleting data
4	A09 Security Logging and Alerting Failures	Someone can guess passwords indefinitely and nobody would ever know it happened
5	A03 Software Supply Chain Failures	Code you didn't write and never reviewed is running inside your application

Number 4 is the one people argue about, because nothing is broken. That's the point of the category: the failure is that an attack leaves no trace, so every other control loses the chance to be noticed.

Notice the impact column never names a category. That's deliberate, and it's the habit worth taking away: the category routes the work to the right team, and the sentence beside it is what gets the work prioritised.

Where this goes next

OWASP gives you names for common live bugs. The next chapter, bug triage, shows how to turn one of those bugs into a report a team can act on.