Who actually attacks web applications, what they're after, and the threat models that matter for SaaS, e-commerce, and B2B platforms in 2026.
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 largest volume of attack traffic against any internet-facing web app. Operators rent or build botnets to:
/wp-admin/, /.env, /.git/HEAD, common admin URLs)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.
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:
Sales prices in 2026 for SaaS admin access: €500 to €25,000 per organization, depending on apparent revenue and data sensitivity.
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:
Specifically dangerous: any app where compromising an admin account also compromises connected systems (SSO providers, Git repositories, cloud infrastructure).
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:
If this is your context, you need a different conversation than this tutorial series alone.
Mapped to monetization paths covered in tutorial 2:
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.
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.
These patterns repeat across countless web app breaches:
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.
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.
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.
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.
A 20-minute exercise for any web app you maintain. Answer in order:
That gap is what to fix this quarter. Repeat the exercise quarterly.
If your app is on the internet today, these are non-negotiable:
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.
Effective defense starts with a realistic picture of who you are defending against, and it is rarely the lone hooded genius of stock imagery. The real landscape includes automated bots scanning indiscriminately for known vulnerabilities, opportunistic criminals monetizing whatever they can, organized groups running credential stuffing and fraud at scale, and occasionally targeted attackers with a specific goal. Most attacks are automated and opportunistic, which means basic hygiene defeats the majority of them. Understanding the spectrum of attackers — their motivations, capabilities, and methods — lets you size your defenses to the threats you actually face rather than to an imagined worst case.
The overwhelming motivation behind web attacks is financial, and seeing this clarifies what attackers want and how they operate. Stolen data is sold, access is ransomed, fraud is committed, and resources are hijacked for profit. Even attacks that look like vandalism often have a monetary angle. This economic reality means your highest-value assets — payment data, personal information, account access, anything that converts to money — are what attackers most want, and therefore what you must protect most. Following the money predicts attacker behavior remarkably well, and aligning your defenses with where the financial incentive points is one of the most practical ways to prioritize security effort.
A crucial distinction shapes your defensive strategy: most threats are automated and indiscriminate, while a few are targeted and persistent. Automated attacks scan the entire internet for known weaknesses and exploit whatever they find, so keeping software patched and avoiding common vulnerabilities defeats the vast majority of them with basic diligence. Targeted attacks, where someone specifically wants into your system, are rarer but more determined and require deeper defenses. Knowing which you are likely to face — most organizations face mostly automated threats — tells you where to invest, and for most, getting the fundamentals right blocks the bulk of real-world attacks.
A sound defensive posture is proportionate to your actual threat landscape rather than driven by fear or fashion. For most applications that means nailing the fundamentals — patching, strong authentication, the OWASP basics, monitoring — which collectively defeat the automated majority, then layering additional defenses according to the value of what you protect and the likelihood of being targeted. Security is about managing risk sensibly, not achieving an impossible perfection. Grounding your effort in a realistic understanding of who attacks web applications and why lets you build defenses that are strong where it matters and not wastefully elaborate where it does not.
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.