How Websites Get Hacked: The Attacker's Mindset, Explained

Your authentication guide journey ended with logins, tokens, and access control working correctly. Here's the uncomfortable news: a site can get all of that right and still be trivially hackable — through a search box, a URL parameter, or a profile picture upload.

This guide covers the rest of web security: how attacks actually work, mechanically, and how to think so you stop writing the bugs that enable them. No fearmongering, no hoodie stock photos — just the machinery.

The mental shift that matters most

Here's the single idea this whole guide builds on.

When you build a feature, you imagine a user: she types her name in the form, clicks submit, sees her profile. You design the happy path, then handle errors — empty fields, bad emails.

An attacker looks at the same form and sees something entirely different: an interface that delivers text of their choosing into your systems. Into your SQL query. Into your HTML. Into your log files, your emails, your admin dashboard. The form is not a form; it's a delivery mechanism.

This is why security bugs are different from ordinary bugs. Ordinary bugs are found by accident, by users trying to do normal things. Security bugs are found on purpose, by people methodically probing every input with abnormal things. You can ship an ordinary bug and maybe nobody hits it. Ship a security bug and someone is looking for it.

Trust boundaries: where the bugs live

The most useful tool in security thinking costs nothing: draw your system and mark every trust boundary — every point where data crosses from something you don't control into something that acts on it.

Almost every classic vulnerability is a failure to treat one of those crossings with suspicion:

Two subtleties make this rule sharper than it looks:

The client is not part of your system. Anything running in the browser — your JavaScript validation, your disabled buttons, your hidden form fields — is running on the attacker's machine, fully inspectable and modifiable. Client-side validation is a UX courtesy. The server must re-check everything, because the server is the first component the attacker doesn't control. (This is the same reason authorization must live server-side.)

Trust is not transitive. Data from your own database feels safe — you wrote it there. But if it originally arrived from a user, it's still attacker-controlled; it just took a detour. Stored attacks (as we'll see with stored XSS) work precisely because developers relax once data is "inside."

Who's actually attacking you

Drop the movie image. Real-world attackers, in order of how likely you are to meet them:

1. Bots and scanners — the overwhelming majority. Automated scripts sweeping the entire internet for known mistakes: exposed .env files, default passwords, unpatched frameworks, login forms to stuff with leaked credentials. They found your site minutes after it went live; they have no idea what it is and don't care.
2. Opportunists with tools — humans running the same scanners plus off-the-shelf exploit kits, following the path of least resistance for spam, crypto miners, or resale of access.
3. Targeted attackers — someone who wants your data specifically. Rarer, far more capable, and the reason defense-in-depth (the final chapter) exists.

The practical consequence: obscurity is not protection. "Nobody knows about my little site" is false — the scanners know, and they're the ones exploiting the basics. The good news is the inverse: because most attacks are automated repetitions of the same handful of mistakes, fixing that handful removes you from almost every attacker's reach.

The map: OWASP Top 10

Which handful? The industry keeps a running answer. OWASP (the Open Worldwide Application Security Project) publishes the Top 10 — a periodically updated ranking of the most prevalent web application vulnerability classes, compiled from real-world breach and scan data.

The recurring cast, grouped the way this guide covers them:

Don't memorise the list — notice its shape. Almost everything on it is either a trust-boundary failure (injection, access control) or a missing layer (encryption, headers, patching). The mindset from this chapter, plus a short list of mechanical habits, covers remarkably close to all of it.

Recap

• Every feature serves two audiences: users and attackers. Secure design means simulating both.
• All input is hostile until proven otherwise — including headers, cookies, uploads, and data returning from your own database.
• Mark the trust boundaries; the classic vulnerabilities are each a blind-trust failure at one specific crossing.
• The client belongs to the attacker — browser-side validation is UX, not security; the server re-checks everything.
• Your realistic adversary is an automated scanner, which means fixing the common, boring mistakes removes most real risk.
• The OWASP Top 10 is the industry's map of those mistakes — and this guide walks its core territory chapter by chapter.

First stop: the security model the browser itself enforces — the thing standing between every website you have open right now. Continue to The same-origin policy & CORS.