Lens 5 · We can't predict everything
Lens 5
We can't predict everything
Injection, authentication, logging, and exceptional conditions. Four risks at the limits of our attention and resources.
01 / 14
Module 3 · Your progress
✓
Risk ≠ vulnerability
✓
What changed and why
✓
Architecture against you
✓
Someone else's code
5
We can't predict everything
Four lenses down. This last one covers four risks that share an uncomfortable truth: we are structurally unable to anticipate everything. Not because we're lazy — because the systems outgrew our capacity to watch them.
02 / 14
Lens 5 · A05 — Injection
One mechanism, many victims
A05 · Injection
The mechanism is always the same: user-supplied data that isn't validated, escaped, or sanitized gets concatenated into something the system executes.
User input → no validation → execution context = injection. SQL queries, OS commands, templates — different victims, identical shape.
Injection dropped from #3 to #5 — partly because modern frameworks sanitize by default. But the category now covers all injection types: SQL, OS command, server-side template, LDAP, XML. Same pattern, wider scope.
03 / 14
Lens 5 · See it happen
SQL injection
The classic, still alive
sql injection
The input wasn't sanitized. The
' OR 1=1 -- turned a WHERE clause into "return everything." Every user record — dumped.04 / 14
Lens 5 · The decisive fix
Parameterized queries
String concat → parameters
✗ String concatenation
query = "SELECT * FROM users
WHERE id = '" + userId + "'"
// userId = "1' OR 1=1 --"
// → dumps entire table
✓ Parameterized query
query = "SELECT * FROM users
WHERE id = $1"
params = [userId]
// userId treated as data
// never as SQL code
The decisive fix: Parameterized queries separate code from data. The database engine knows the parameter is a value, not part of the query structure. No amount of creative input can escape the parameter boundary.
05 / 14
Knowledge check
Knowledge check
Which of these attacks is NOT an injection?
C — IDOR is not an injection. IDOR is an access control failure (A01) — the attacker changes a reference (like a user ID in a URL) to access someone else's data. No code is injected. SQL injection, XSS, and template injection all follow the same pattern: user input executed as code. IDOR is about authorization, not execution.
06 / 14 · Quiz
Lens 5 · A07 — Authentication failures
Password rules ≠ strong passwords
A07 · Authentication Failures
Scenario
A password meets every requirement: uppercase, lowercase, special characters, numbers, minimum length. It passes all validation. Is it strong?
Not necessarily. The password could already be on a leaked list. It could be vulnerable to daisy-chaining attacks. Meeting every rule says nothing definitive about strength.
Two practical defenses: password dictionary check — compare against a database of known-compromised passwords (some libraries ship this directly). And encourage password managers — the only realistic way to get unique, high-entropy passwords for every service.
Brute-forcing without rate limiting, transmitting passwords without proper protection (HTTPS alone isn't enough — hash on the front end), exposing session identifiers in URLs. The compensating controls available are limited, and that's why this category persists.
Champion's takeaway
Password complexity rules create a false sense of security. Credential stuffing doesn't care about your special characters — it uses real passwords from other breaches.
07 / 14
Myth vs reality
🔒
Common assumption
"Strong password rules = strong passwords"
Reality
A password that passes every rule — uppercase, lowercase, numbers, special characters, minimum length — can still be on a leaked password list. Password rules check format, not uniqueness. The real defense: dictionary checks against known-compromised passwords + password managers for generation. Rules create a false sense of security. Verification against real-world leaks is what actually reduces risk.
08 / 14
Knowledge check
Knowledge check
Scenario
The password
Tr0ub4dor&3 — uppercase, lowercase, numbers, special characters. Meets all rules.Is this password secure?
B — It's a well-known example and likely in leak databases. Tr0ub4dor&3 is famous from the XKCD password strength comic. It appears in password dictionaries, research papers, and security presentations worldwide. Complexity requirements don't protect against passwords that are already known. A password manager generating a random 20+ character string is more secure than any human-memorable pattern, regardless of how many rules it satisfies.
09 / 14 · Quiz
Lens 5 · A09 — Logging & monitoring
Signal vs. noise
A09 · Logging & Monitoring Failures
This risk has two roots. First: separating signal from noise. You can log everything — but it's too expensive and kills performance. Deciding what to log for each component is itself a bulk of work.
There are billion-dollar companies — just for storing telemetry and providing analysis. That's how big the signal-vs-noise problem is.
Second: the number of sources. Traffic, container orchestrators, databases, operating systems, application logs — each with different mechanisms for what to log, where to store it, how to gather it.
What actually happens
"We'll just gather NetFlow, or metadata, or logs from the application — and skip the databases, orchestrators, etc." That shortcut is exactly how coverage gaps form.
Logging and monitoring are covered in operational depth in Module 8 (Incident Response) — including alert funnels, tuning, and what to prioritize.
10 / 14
Lens 5 · A10 — Exceptional conditions
The structural limit
A10 · Mishandling of Exceptional Conditions
Key principle
"Everything is more simple. We are not able to take into consideration everything. Our tools became more and more complex — providing more functions, more data objects, more capacities. It's absolutely obvious that it's difficult to predict all potential behavior."
This is the newest risk on the list. The root cause isn't that developers forget edge cases — it's a structural limit on what we can anticipate. Tools grow because clients demand more and competition forces it. The unpredicted-behavior surface grows with the tools.
This trend is here to stay. More features = more exceptions = more unpredicted behavior. We are limited in resources, time, and our capacities. That's why this risk was raised.
How to respond when the unpredictable happens is the focus of Module 8 (Incident Response) — runbooks, containment, and operational recovery.
11 / 14
Lens 5 · The picture
Your attention is a spotlight. It can only illuminate one or two components at a time. The rest sit in the dark. You can't watch everything. That's the point.
12 / 14
Lens 5 · What we covered
Lens 5 complete
We can't predict everything
A05 — Injection: one mechanism (user input → no validation → execution), many victims (SQL, OS, templates). Parameterized queries are the decisive fix.
A07 — Authentication Failures: password rules check format, not uniqueness. Dictionary checks + password managers are the real defense. HTTPS alone isn't enough.
A09 — Logging & Monitoring: two roots — signal vs. noise, and the number of sources. Teams shortcut, gaps form, incidents go undetected.
A10 — Exceptional Conditions: a structural limit, not laziness. Tools grow, complexity grows, the unpredicted surface grows with them.
Your score: calculating...
13 / 14
Lens 5 · Done
All 5 lenses complete
You can't watch everything. But you can decide what to watch first.
That's the full OWASP Top 10 — not as a checklist, but as five ways of seeing where risk lives in your system. Next up: putting it all together.
Your action this week: pick one component of your product. Ask one question from the Top 10 — is there an access control gap? A hardcoded secret? A dependency nobody audited? File what you find, even a one-line ticket. The habit of looking is more valuable than the size of the finding.
14 / 14
⏸ Pause to reflect