You've completed 10 modules. Each one taught a category in isolation. Production systems don't work that way — vulnerabilities overlap, resources are finite, and you can't fix everything at once.

Ten scenarios follow. In each one, two OWASP categories intersect. Both fixes are real. Both matter. But you have budget for one. Pick the higher-leverage fix.

// meet your learning buddy

The search endpoint that talks too much

An internal API accepts user input in a search query and passes it to a SQL backend. The input is parameterized — but the error handler is not. When a query fails, the endpoint returns detailed error messages: table names, column types, query structure. When a query targets a nonexistent table, it returns a different error than when it targets an existing table with wrong permissions.

The query is parameterized (A05 injection is mitigated). But the error responses are a reconnaissance goldmine (A10 information disclosure). Two categories, one endpoint.

Higher leverage: fix the error responses (A10).

The parameterized query already blocks SQL injection — the A05 risk is mitigated. But the verbose error messages hand an attacker a map of your database on every failed request.

The build server that trusts everything

A CI/CD pipeline pulls dependencies from npm without a lockfile pinned to exact hashes. The package-lock.json exists but isn't committed — npm install resolves fresh ranges on every build.

Two supply chain risks: unpinned dependencies that could be swapped for malicious versions (A03), and a build environment on the same network as developer laptops — reachable via lateral movement (A08).

Higher leverage: isolate the build server (A08).

Lockfile pinning stops one attack vector — dependency substitution. But if the build server is reachable from compromised endpoints, an attacker doesn't need to poison a package. They can inject code directly into the build process, modify artifacts, or exfiltrate secrets from CI environment variables.

The password reset nobody rate-limits

A SaaS application has two authentication paths. The login page uses email + password — no MFA. The password-reset flow sends a 6-digit code by email, valid for 15 minutes. There's no rate limit on reset code attempts.

The reset flow is a design flaw — a guessable code without rate limiting (A06). The login page lacks MFA (A07). Budget for one fix this quarter.

Higher leverage: add MFA to login (A07).

The login page is the primary authentication path — it's hit by credential stuffing attacks daily. MFA blocks them all, regardless of how the credentials were obtained.

The reset flow is vulnerable, and fixing it matters — but the login page is where the volume is. Protecting the front door beats reinforcing the side entrance.

The admin panel nobody changed the password for

A monitoring dashboard (Grafana) is exposed on the internal network with default credentials. It has read access to production metrics, database connection health, and service topology. The organization also has no centralized security logging.

Default credentials on an admin panel (A02 security misconfiguration). No security monitoring or alerting (A09 logging failures). The team can fix one this sprint.

Higher leverage: change the credentials (A02).

Default credentials are exploitable right now, by anyone on the network, with zero skill required. The Grafana panel gives an attacker production connection strings and service topology — a foothold for lateral movement.

Centralized logging helps you detect attacks — but it doesn't stop one that's already possible through an open door. Close the door first, then build the alarm system.

The microservice that trusts everyone

A backend microservice accepts JWTs from the API gateway but doesn't validate the signature — it base64-decodes the payload and trusts the claims. The same service runs as root in its container.

Missing JWT signature validation means anyone can forge tokens (A01 broken access control). Running as root means a container escape gives the attacker host-level access (A02 security misconfiguration). Both are real — but which one creates the vulnerability?

Higher leverage: validate the JWT signature (A01).

Without signature validation, anyone can forge a token with any claims. The service has no access control at all. Running as root worsens the blast radius but doesn't create the vulnerability.

The API keys hashed with MD5

An internal service stores API keys for 200+ partner integrations. The keys are hashed — but with unsalted MD5. Meanwhile, a dependency audit flagged a medium-severity CVE in a logging library. No known exploit, CVSS 5.3.

MD5-hashed API keys without salt (A04). A medium-severity CVE with no known exploit (A03). One fix this sprint.

Higher leverage: re-hash the API keys (A04).

Unsalted MD5 hashes are reversible in seconds. A leaked database gives an attacker every partner's API key immediately. The CVE is medium-severity with no known exploit — a future risk. The MD5 keys are a present one.

The report builder that concatenates SQL

An admin dashboard has a custom report builder. Most queries use the ORM — but the "advanced filter" concatenates user input directly into SQL. The same endpoint also lacks tenant-level authorization.

SQL injection via string concatenation (A05). Missing tenant-level access control (A01). Both on the same endpoint.

Higher leverage: parameterize the SQL (A05).

SQL injection gives full database access — UNION SELECT * FROM users bypasses any row-level check. Tenant authorization limits what the application shows; injection lets the attacker talk directly to the database.

The file upload that accepts anything

A document-sharing feature lets users upload files with no validation — type, size, or content. The server saves whatever it receives to a publicly accessible directory. The download endpoint doesn't check ownership either.

Unrestricted file upload to a public directory — potential RCE via webshell (A06). Download endpoint missing ownership check (A01). Budget for one fix.

Higher leverage: validate the uploads (A06).

Unrestricted file upload to a public directory = remote code execution. Upload shell.php, visit /uploads/shell.php, own the server. Broken download auth leaks documents — serious, but not code execution.

The typosquatted package already in the build

A security scan discovered lodsah (not lodash) in package.json. It was installed 8 months ago and runs a postinstall script on every npm install. Separately, the password policy allows 123456 and password.

Active malware in the dependency tree running on every build (A03). Weak password policy allowing common passwords (A07). One fix first.

Higher leverage: remove the typosquatted package (A03).

This isn't a vulnerability — it's an active compromise. The malware has been running for 8 months on every build. It may have exfiltrated env vars, tokens, and source code. Weak passwords are a risk; the supply chain compromise is a breach in progress.

The brute-force nobody notices

A login endpoint is receiving 500+ failed auth attempts per minute from rotating IPs. The app logs them — but nobody is watching. No alerting, no SIEM, no on-call trigger. Error responses on the same endpoint return stack traces with internal service names.

No security alerting on auth failures (A09). Stack traces leaking internals (A10). One fix this sprint.

Higher leverage: set up alerting (A09).

500 failed logins/min is an active attack running undetected. Without alerting, credential stuffing runs for days until a hit succeeds. Stack traces leak info, but the attacker already has enough to attack. The alert stops the bleeding.

// the ten habits — one from each module

// triage complete