I want to open with a number that stopped me cold when I first read it: 43% of all cyberattacks target small businesses. Not governments. Not Fortune 500 corporations. Small businesses, the kind run by people who genuinely believe they're too small to be noticed.

That assumption is exactly the vulnerability attackers are counting on.

I've spent considerable time studying web and application security not just reading about it, but actually getting into the weeds with tools like OWASP ZAP, running test environments with XAMPP, and studying attack patterns from real breach post-mortems. What I found was this: most devastating attacks are not sophisticated. They're the result of developers not knowing what they were building against, and users not knowing what they were clicking on.

This article is my attempt to change that, at least in a small way.

Why Web Applications Are Such a Ripe Target

Before we get into specific vulnerabilities, it's worth pausing to ask: why are web applications specifically so attractive to attackers?

The answer is threefold.

Surface area. A web application, by definition, is exposed to the internet. Unlike a desktop application that runs locally, a web app has HTTP endpoints, form fields, cookies, session tokens, APIs, and database connections all of which represent potential entry points. The more complex the application, the larger the attack surface.

Value density. Web applications consolidate enormous amounts of sensitive data. A single e-commerce platform might hold payment card information, shipping addresses, purchase histories, and login credentials for hundreds of thousands of users. That's a single breach yielding massive, immediately monetised data.

Inconsistent development standards. Unlike, say, aerospace or medical device software (which are governed by rigorous engineering standards), web development has no universal security baseline. One developer might use parameterised queries religiously; another on the same team might concatenate raw user input directly into SQL strings. Both approaches can exist in the same codebase.

This inconsistency is the real enemy. Not hackers with exotic zero-day exploits just developers who didn't know better, under deadline pressure, shipping features faster than they shipped security.

SQL Injection: Still Alive, Still Devastating

Let me be direct: SQL Injection should be a solved problem. It was first documented in 1998. The fix is well-understood, freely documented, and takes minutes to implement. And yet it consistently appears in breach reports, OWASP Top 10 lists, and CVE databases every single year.

That tells us something important: the technical solution being available doesn't mean it gets applied.More advanced variants can do far worse. UNION-based injection lets an attacker append their own SELECT statement to extract data from any table in the database. Blind SQL injection works even when the application doesn't display query results the attacker infers data by asking yes/no questions and observing how the application responds.

What strikes me about SQL injection is not the technical complexity (it isn't) but the psychology of why it persists. Developers under pressure take shortcuts. Legacy codebases don't get refactored. Tutorials that teach the basics don't always teach secure versions of those basics. The result is entire applications built on foundations that crack under the first targeted probe.

Cross-Site Scripting (XSS): Turning Your Website Into a Weapon

XSS is, in my view, one of the most underappreciated threats in web security — both because of how elegantly simple the attack vector is, and how severe the consequences can be.

The premise: a web application accepts user input (a comment, a search query, a profile bio) and reflects that input back in the page without properly encoding it.

There are three primary variants worth understanding:

Stored XSS (also called persistent XSS) is what I described above — the malicious script is saved in the database and served to every visitor. This is the most dangerous form because it scales automatically.

Reflected XSS requires the victim to click a crafted link. The malicious script is embedded in the URL, gets processed by the server, and reflected back in the response. Phishing emails often deliver this type.

DOM-based XSS never touches the server at all. The attack manipulates how client-side JavaScript reads and writes to the DOM. These are particularly tricky to detect because they don't appear in server logs — they're entirely a browser-side phenomenon.

Broken Authentication: The Wide-Open Front Door

Authentication is the gatekeeper of every web application. When it breaks down — and it breaks down in more ways than most people realise — everything behind it becomes accessible.

The OWASP definition of "broken authentication" covers a broad family of weaknesses:

Weak credential policies. Applications that allow passwords like "password123" or "123456" are essentially offering attackers a shortlist to try first. Credential stuffing attacks — where breached username/password pairs from one service are automatically tested against others — are devastatingly effective precisely because people reuse passwords. A breach at Site A becomes a breach at Sites B, C, and D if the credentials are the same.

Missing account lockout. If an application allows unlimited login attempts, an attacker can run a brute-force attack indefinitely. Modern GPU-assisted tools can attempt billions of password combinations per second. Without rate limiting or progressive delays, even moderately complex passwords can be cracked.

Insecure session tokens. After authentication, applications issue a session token — a string that identifies the logged-in user on subsequent requests. If that token is short, numerically sequential, or derived from predictable inputs (like a timestamp), an attacker can guess other valid tokens and hijack other users' sessions.

Sessions that never expire. A session that persists indefinitely is a security liability. If a token is ever stolen — via XSS, network interception, or simply left on a shared computer — the attacker retains access forever.

Session Hijacking: Identity Theft in Real Time

Session hijacking deserves its own section because it's often conflated with authentication attacks when it's actually a distinct threat operating at a different layer.

Authentication is about proving who you are. Sessions are about maintaining that proof across multiple requests, since HTTP is inherently stateless.

The attack: an adversary captures a valid session token and presents it to the server. The server, which can only see the token, has no way to know it's not the original user. From the server's perspective, the session is valid.

How does an attacker get the token? Several ways:

Network sniffing on unencrypted connections (HTTP rather than HTTPS) allows tokens transmitted in cookies or URL parameters to be intercepted. This is particularly dangerous on public Wi-Fi networks where traffic may be visible to other devices.

Cross-site scripting, as discussed above, can extract tokens from the browser's cookie storage and send them to an attacker.

Cross-Site Request Forgery (CSRF) is a cousin of session hijacking — it tricks the browser into making authenticated requests on behalf of the attacker, without stealing the token directly.

The Psychological Dimension: Why Technical Solutions Aren't Enough

I want to step back from the technical specifics for a moment, because I think the most under examined aspect of web security is human behaviour.

Consider phishing. It's arguably the most prevalent attack vector in enterprise security incidents, and it works not because people are foolish but because it's designed to exploit cognitive shortcuts under conditions of urgency, authority, and familiarity.

A well-crafted phishing email:

• Arrives from an address that closely resembles a legitimate sender
• References real context (a package delivery, an account problem, a colleague's request)
• Creates a time-sensitive scenario ("Your account will be suspended in 24 hours")
• Directs to a page that is visually indistinguishable from the real site

Under those conditions, even technically sophisticated people make mistakes. I've seen security professionals — people who teach others about phishing — fall for well-targeted spear phishing because the attacker had done their research.

The Developer's Responsibility: Secure by Default

I'll close with what I think is the most important insight from studying this field: security cannot be an afterthought.

When security is treated as a phase that happens after features are built — when it's a checklist item before deployment rather than a design constraint from day one — vulnerabilities compound. Technical debt accrues. The cost of fixing a SQL injection vulnerability in a codebase that has already shipped and scaled is orders of magnitude higher than writing a parameterised query from the beginning.

The shift that needs to happen is treating security the way we treat correctness. A function that produces wrong outputs is a bug. A function that produces correct outputs but is vulnerable to injection is also a bug — it's just a bug that only manifests when someone is actively trying to exploit it.

Tools like OWASP ZAP, Burp Suite, and static analysis tools integrated into CI/CD pipelines make it possible to catch many classes of vulnerability before they ever reach production. The OWASP Top 10 gives every development team a concrete, authoritative baseline of what to defend against. The knowledge exists. The tools exist.

Final Thought

Web and application security is one of those fields where the gap between knowing and doing is dangerously wide. The concepts aren't mysterious. The fixes aren't extraordinary. What's required is sustained attention — from developers who build defensively, organisations that fund security rather than deprioritise it, and users who understand that their habits are part of the system too.

The threat landscape will evolve. New attack patterns will emerge. But the fundamental posture — understand how things break, build so they don't, and stay alert when they might — remains constant.

If you've read this far, you already have more context than the majority of people interacting with web applications every day. Use it well.