Lens 2 · What changed and why
Lens 2
What changed and why
The OWASP Top 10 got updated. The interesting part isn't what moved — it's what the movement tells us about how we build software now.
2125
01 / 14
Module 3 · Your progress
Risk ≠ vulnerability
2
What changed and why
3
Architecture against you
4
Someone else's code
5
We can't predict everything

Lens 1 covered the foundation: risk ≠ vulnerability. Now we look at how the Top 10 evolved — and what that tells us about the way we build software today.

02 / 14
Lens 2 · The two lists
2021 vs 2025
One look, then we move on to why
The positions matter less than the patterns. Look at what rose — those are the signals.
  1. Broken Access Control
  2. Cryptographic Failures
  3. Injection
  4. Insecure Design
  5. Security Misconfiguration
  6. Vulnerable & Outdated Components
  7. Identification & Auth Failures
  8. Software & Data Integrity Failures
  9. Security Logging & Monitoring Failures
  10. Server-Side Request Forgery
  1. Broken Access Control same
  2. Security Misconfiguration ↑ from #5
  3. Software Supply Chain Failures ↑ from #6
  4. Cryptographic Failures ↓ from #2
  5. Injection ↓ from #3
  6. Insecure Design ↓ from #4
  7. Identification & Auth Failures same
  8. Software & Data Integrity Failures same
  9. Security Logging & Monitoring Failures same
  10. Mishandling of Exceptional Conditions new
What to notice
Don't memorize positions. Notice what rose — those are the signals about how modern software is built and attacked.
03 / 14
Knowledge check
Your guess first
Which change in the 2025 list is most directly caused by the fact that we compose software from third-party packages instead of writing from scratch?
B — supply chain rose to #3. We use hundreds of dependencies we didn't write, didn't audit, and often don't fully understand. The other changes have different root causes: misconfiguration rose because of infrastructure complexity, injection dropped partly because frameworks now sanitize by default.
04 / 14 · Quiz
Lens 2 · How we got here
From writing to composing
Step by step
1
We stopped writing from primitives
Modern teams compose applications from packages, frameworks, and services. Less code written, more code reused.
2
Dependencies grew to hundreds
A typical project has 200–1,500 transitive dependencies. Each one is someone else's code running in your product.
3
Trust became implicit
Most teams install packages without auditing the source. Popular = safe. That assumption is the vulnerability.
4
One compromised dependency deep in the tree — you're exposed
A CVE four levels deep in your dependency tree is still running in production. Your scanner may not flag it.
05 / 14
Lens 2 · See for yourself
What your project looks like right now
dependency check
You can run these exact commands in your own project.
06 / 14
Myth vs reality · 1 of 3
🛡️
Common assumption
"We're behind Cloudflare, so misconfiguration isn't our problem"
Reality
Cloudflare is a compensating control — it reduces risk, but doesn't eliminate the need for proper configuration. Three things that go wrong regularly: WAF left in monitoring mode instead of blocking, rate limiting rules too loose to stop credential stuffing, origin server IP exposed letting attackers bypass Cloudflare entirely. Teams treat Cloudflare as a security guarantee instead of a security layer. That gap is exactly what A02 (Security Misconfiguration) measures.
07 / 14
Myth vs reality · 2 of 3
🔑
Common assumption
"SSO means our authorization is solved"
Reality
SSO solves authentication — confirming identity. But authorization — who can access what — still happens inside each service separately. Every microservice parses the token and makes its own access control decisions. One service might check role claims. Another might not. A third might cache permissions and miss revocations. SSO gives you a verified identity. What each service does with it is where A01 (Broken Access Control) lives.
08 / 14
Myth vs reality · 3 of 3
🔐
Common assumption
"We don't write crypto, so crypto failures don't apply to us"
Reality
You don't write cryptographic algorithms — but you make cryptographic decisions every day. Which TLS versions to allow. How to store API keys — plaintext env vars or secrets manager? Whether to enforce certificate pinning. How often to rotate credentials. Each wrong answer is a cryptographic failure under A04 — even with zero lines of crypto code. The "boring crypto" principle says use existing libraries. Correct — but using existing crypto correctly is its own skill.
09 / 14
Knowledge check · scenario
Knowledge check
Scenario
A colleague disables the WAF for two hours to debug a false positive in production. The debug is successful. The colleague forgets to re-enable the WAF. Three weeks pass.
What OWASP risk category does this fall under?
B — Security Misconfiguration. The WAF wasn't broken or badly designed — it was configured incorrectly (turned off and left off). This is exactly how misconfiguration jumped to #2: our dependence on external controls means forgetting to re-enable one is itself a vulnerability.
10 / 14 · Quiz
Lens 2 · What's missing
What's missing from the list
Vibe coding — generating code with LLMs without deep review — isn't on the 2025 list. That's not because it's safe. It's because OWASP's data collection cycle closed before vibe coding became widespread.
LLM-generated code that goes to production without security review is supply chain risk that hasn't been catalogued yet.
A10 (Mishandling of Exceptional Conditions) replaced Server-Side Request Forgery from 2021. The reason: our tools have become so complex that predicting every possible behavior is structurally impossible. It's about the limits of what we can anticipate when systems have thousands of possible states.
Champion's takeaway
Vibe coding isn't on the 2025 list yet. As a Champion, start tracking LLM-generated code in your reviews — you'll be ahead of the next revision.
11 / 14
Time to think · Your attack surface
YOUR CODE DEPENDENCIES CONFIG & CONTROLS INFRA & SERVICES 🛡

Your code is the small circle in the center. Everything around it — dependencies, configurations, infrastructure — is part of your attack surface. The risks that grew in 2025 are all in the outer rings.

12 / 14
Knowledge check · real scenario
Knowledge check
Scenario
Your product has 340 npm dependencies. A critical CVE is published for a package that's a transitive dependency four levels deep.
What's the most realistic outcome?
D — it depends on your tooling. Without automated scanning (Dependabot, Snyk, npm audit in CI), a transitive CVE four levels deep is practically invisible. With it, you get an alert within hours. The difference between A and B/C is one configuration choice — which brings us back to the theme: the infrastructure around your code matters more than the code itself.
13 / 14 · Quiz
Lens 2 · Complete
Lens 2 complete
What changed and why
The 2021→2025 shift isn't about OWASP changing its mind. It's about development changing its shape: more composition, more configuration, more dependency on things we don't control.
Supply chain rose because we compose more than we write. Misconfiguration rose because forgetting to configure a control is now itself a vulnerability. Exceptional conditions appeared because our tools outgrew our ability to predict their behavior.
Your score: calculating...
Next: Lens 3 — broken access control, misconfiguration, and insecure design. Three risks with a common root: architectural decisions that create risk by default.
14 / 14