The Web Application Threat Landscape — Real Attackers, Real Targets, Real Money

Why "web app" is a special case

Web applications carry more business value, store more customer data, and accept more attacker-controlled input than any other class of software you run. Every day on the internet, your login form is touched by credential-stuffing botnets. Your /api/ endpoints are probed by automated scanners. Your password reset flow is tested for enumeration.

This series is about understanding those threats at the technical depth required to defend production web apps — not generic "awareness training" content. We're starting with the threat landscape because everything else depends on knowing who's actually attacking and why.

The four attacker categories that hit web apps daily

1. Automated scanners and botnets

The largest volume of attack traffic against any internet-facing web app. Operators rent or build botnets to:

• Credential stuff — try usernames/passwords from one breach against every other login form
• Web shell scan — probe for known file paths (/wp-admin/, /.env, /.git/HEAD, common admin URLs)
• Vulnerability scan — exploit known CVEs in popular frameworks within hours of public disclosure
• Cryptominer drop — once they get RCE, install miners pointed at attacker-controlled pools
• DDoS infrastructure — your compromised app becomes part of the next attack

You will see this traffic on day one of going live. The defenses are basic but mandatory: WAF + rate limiting + patched dependencies + MFA. Get them in place before launch.

2. Initial Access Brokers (IABs)

A specialized criminal economy: attackers whose only job is to break in and sell access to others. They don't deploy ransomware themselves; they sell credentials and shell access to the gangs that do.

What they target in web apps:

• Admin panels behind weak passwords with no MFA
• CI/CD platforms with leaked credentials in commit history
• Cloud consoles (AWS, GCP, Azure) accessed via web
• CMS backends (WordPress, Drupal, custom admins) running outdated code

Sales prices in 2026 for SaaS admin access: €500 to €25,000 per organization, depending on apparent revenue and data sensitivity.

3. Ransomware affiliates

The crime groups that pay IABs. Their web app angle is access-to-pivot — once they get into your admin panel or developer accounts, they pivot to internal infrastructure where the real damage happens (file servers, domain controllers, backup systems).

Web apps are increasingly the initial vector because:

• VPN gateways are now better-patched and locked down
• RDP is mostly off the internet
• But web app admin panels, dev tools, and SaaS integrations have grown the attack surface

Specifically dangerous: any app where compromising an admin account also compromises connected systems (SSO providers, Git repositories, cloud infrastructure).

4. Targeted attackers and APTs

Most web apps aren't worth this level of attention. The exceptions: defense contractors, journalists' tools, dissident communications, government suppliers, financial services with high-value transactions. If you fall into one of these, your threat model includes professional, well-resourced adversaries with custom tooling.

Indicators you're a target:

• Specific industry alerts from your sector ISAC
• Spear-phishing attempts tailored to your business
• Long-dwell incidents found in audits (months of undetected access)
• Anomalous activity on developer or admin accounts

If this is your context, you need a different conversation than this tutorial series alone.

What attackers actually want from your web app

Mapped to monetization paths covered in tutorial 2:

1. Credentials — your users' login credentials, especially admin or staff. Resold or used for downstream attacks.
2. Payment data — credit card numbers (PCI breach), stored payment methods, Stripe API keys for fraudulent charges.
3. Customer PII — emails, names, addresses, identification documents. Used for fraud, sold in bulk, leveraged for further phishing.
4. Business data — customer lists, contracts, internal communications. Used for blackmail or competitive espionage.
5. Computing power — your servers become cryptominers, DDoS nodes, proxy servers.
6. Access for pivots — your app is the entry point to higher-value targets.
7. Brand abuse — your domain hijacked to host phishing pages targeting your own customers.

The defense priorities depend on which of these matters most for your specific app. A small content site mainly defends against #5 and #7. A SaaS with payment data defends primarily against #1, #2, and #6.

The web app attack chain

Most successful breaches against web apps follow a recognizable pattern:

1. Reconnaissance     — find the target, map the attack surface
2. Initial access     — credential reuse, phishing, exploit a vuln
3. Persistence        — get a foothold that survives password changes
4. Privilege escalation — go from low-priv user to admin
5. Lateral movement   — pivot to other systems/accounts
6. Action on objective — exfiltrate data, deploy ransomware, fraudulent transfers

Each step has tools and techniques (covered in tutorials 7-9). Each step has detection opportunities (covered in tutorial 10). The defenses you build should slow the attacker at multiple stages so detection has time to catch up.

Real-world incident archetypes

These patterns repeat across countless web app breaches:

"Credential stuffing into staff account"

User reuses password from old breach. Attacker tries it on your admin login. Account has no MFA. Attacker now has full admin access. Exports customer database. Posts it for sale on dark forums.

Defense layers that would have stopped it: MFA, breach password blocking (HaveIBeenPwned check on login), rate limiting + anomaly detection on auth, audit logs of admin actions, alerts on bulk export operations.

"Phishing-to-OAuth"

Attacker sends spear-phishing email to a target with a link to a malicious OAuth app. Target clicks "Authorize." Attacker now has long-lived OAuth token, no need for password or MFA. Pivots through connected services (Slack, GitHub, Gmail).

Defense layers: OAuth app approval workflows, monitoring of token grants, principle-of-least-privilege on scopes, ability to revoke tokens centrally, user training on OAuth consent screens.

"Vulnerable dependency RCE"

Your app uses a popular library with a fresh CVE. Within hours of disclosure, internet-wide scanners are exploiting it. Your app gets a web shell installed. Attacker uses it to read secrets, then pivots to your cloud account via the IAM role.

Defense layers: automated dependency scanning + patching SLA, restricted server permissions (process can't read arbitrary files), egress filtering (web shells need C2 to be useful), runtime intrusion detection.

"BEC-to-wire-fraud via web admin"

Phishing compromises the CFO's email account. Attacker doesn't ransomware — they sit silently for a week, learn the wire transfer process, then send a properly-styled email to AP requesting a vendor payment to a controlled account. AP processes it. €240K gone.

Defense layers: MFA on email, DMARC enforcement, dual approval for transfers, out-of-band verification for changes to vendor banking, training that doesn't shame people for being targeted.

Building your threat model

A 20-minute exercise for any web app you maintain. Answer in order:

1. What does the app do? (Plain English, two sentences.)
2. What does it store that's valuable? (Data inventory.)
3. Who would attack it? (Pick from the categories above.)
4. How would they attack it? (Pick from the chain above; what's the easiest path?)
5. What would the impact be? (Revenue, regulatory, reputational.)
6. What controls exist today? (List them honestly.)
7. Where's the biggest gap? (Where the easiest attack path meets the weakest control.)

That gap is what to fix this quarter. Repeat the exercise quarterly.

The minimum viable defense for any web app

If your app is on the internet today, these are non-negotiable:

• TLS everywhere, HSTS enabled, modern cipher suites only
• MFA on all admin and staff accounts — phishing-resistant if possible (WebAuthn)
• Rate limiting on auth endpoints (5/min/IP minimum)
• Account lockout on repeated failures (with timing-safe responses to prevent enumeration)
• Patched framework and dependencies with automated alerts on new CVEs
• WAF in front (Cloudflare free tier, ModSecurity, AWS WAF — anything beats nothing)
• Logging of all auth events, admin actions, 4xx/5xx errors to a centralized aggregator
• Sentry or equivalent wired into the application
• Encrypted backups with immutability and tested restore process
• Documented incident response playbook even if it's one page

Beyond this floor, the rest of this tutorial series goes deep on advanced techniques and defenses. But start here. The fancy stuff doesn't help if these basics are missing.

What's coming in this series

Tutorial 2 — How attackers monetize web app compromise specifically Tutorial 3 — The dark side of web app data after a breach Tutorial 4 — HTTP, TLS, cookies, headers — the attack surface in depth Tutorial 5 — Beyond OWASP Top 10 Tutorial 6 — WAF bypass and application-layer defenses Tutorial 7 — Advanced web app reconnaissance Tutorial 8 — Authentication attacks (sessions, JWT, OAuth, SSO) Tutorial 9 — Red team tactics specific to web apps Tutorial 10 — Investigating a live web app compromise

The whole series assumes you're already comfortable with Django, HTTP, and the basics of web security. The point isn't to introduce concepts — it's to go deep enough to build defenses that actually hold under realistic attack.