The Most Common Web App Attacks Explained Simply: SQLi, XSS, CSRF, SSRF, RCE

Web applications are exposed to the internet, accept untrusted input, and usually connect to powerful internal systems like databases, file storage, and cloud metadata services. That combination makes them a prime target. Most real-world breaches don’t require “movie hacking”, they come from a small set of repeatable attack patterns.

This article explains five of the most common web app attacks in plain language: SQL Injection (SQLi), Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Server-Side Request Forgery (SSRF), and Remote Code Execution (RCE), what they are, how they work, and how teams prevent them.

SQL Injection (SQLi)

What it is

SQL injection happens when an application builds database queries by concatenating user input into SQL strings. If the input isn’t handled safely, an attacker can insert SQL syntax that changes what the query does.

How it works (simple example)

Imagine a login query like:

SELECT * FROM users WHERE email = ‘INPUT’ AND password = ‘INPUT’;

If the app directly inserts whatever the user typed, an attacker might enter something crafted to make the condition always true, or to extract data from other tables. SQLi can allow reading sensitive information (user records, payment data), changing data, or even dropping tables.

Why it’s still common

SQLi keeps showing up because it’s easy to reintroduce accidentally:

• Legacy code
• Quick fixes
• New endpoints built without secure patterns
• Developers misunderstanding ORM “escape hatches” (raw queries)

How to prevent it

The core fix is straightforward: never concatenate untrusted input into SQL.

• Use parameterized queries / prepared statements.
• Use ORMs safely (avoid raw SQL unless strictly necessary).
• Apply least-privilege database accounts (an app user shouldn’t have admin rights).
• Add detection via WAF rules and monitoring, but treat those as backup, not the primary defense.

Cross-Site Scripting (XSS)

What it is

XSS occurs when an attacker manages to get malicious JavaScript to run in another user’s browser within the context of your site. When it works, the attacker can steal sessions, change what users see, or perform actions as the victim.

Three common types

1. Stored XSS: The payload is saved on the server (for example, in a comment field) and served to other users later.
2. Reflected XSS: The payload is sent in a request and immediately reflected back in the response (like an error message or search page).
3. DOM-based XSS: The vulnerability lives in front-end JavaScript that writes untrusted input into the page unsafely.

Why it’s dangerous

If your site uses cookies or tokens for authentication, XSS can lead to account takeover. Even with HttpOnly cookies (which help), attackers can still perform actions in the victim’s session by manipulating the page or making requests.

How to prevent it

XSS prevention is about output encoding and safe rendering:

• Use templating frameworks that escape by default.
• Avoid inserting raw HTML from users (innerHTML) unless it’s sanitized.
• Use Content Security Policy (CSP) to reduce impact if something slips through.
• Sanitize rich text with proven libraries, not custom regex.
• Mark cookies as HttpOnly and Secure, and use SameSite where possible.

Read: 5 Key Differences Between Android and Web Development You Should Know

Cross-Site Request Forgery (CSRF)

What it is

CSRF tricks a logged-in user’s browser into requesting your site without the user intending to. The key detail: the browser automatically attaches cookies, so the server sees a legitimate authenticated request.

How it works

If you’re logged into a banking site in one tab, and you visit a malicious site in another tab, that malicious page could trigger a request like “transfer money” or “change email,” and your browser might send it along with your session cookie. If your server doesn’t verify that the request came from your real app, it may accept it.

When it’s most likely

CSRF is most common when:

• Authentication uses cookies
• State-changing actions are accepted without extra verification
• There’s no CSRF token or origin validation

If you use bearer tokens stored outside cookies (like in memory and added manually), CSRF is less likely, but you may increase XSS risk if tokens are stored unsafely.

How to prevent it

• Use CSRF tokens on state-changing requests (POST/PUT/PATCH/DELETE).
• Validate Origin and/or Referer headers for sensitive actions.
• Set cookies with SameSite=Lax (or Strict where feasible).
• Avoid using GET requests for actions that change state.

Server-Side Request Forgery (SSRF)

What it is

SSRF happens when an attacker makes your server send requests to locations the attacker shouldn’t be able to reach. The attacker doesn’t send the request directly, they use your server as a proxy.

Why it matters

Your servers often have access to internal networks and cloud-only endpoints that are not exposed publicly. A classic SSRF target is the cloud instance metadata service (which can reveal credentials or tokens), but SSRF can also reach internal admin panels, private APIs, or databases.

Common SSRF entry points

• “Fetch this URL” features (image importers, link previews, PDF generators)
• Webhooks and callback URLs
• File conversion services that pull remote resources

How to prevent it

SSRF defense is about controlling where the server is allowed to connect:

• Maintain an allowlist of permitted domains/hosts for outbound fetches.
• Block access to internal IP ranges (localhost, 169.254.169.254, RFC1918 ranges).
• Use safe DNS resolution rules (to prevent DNS rebinding tricks).
• Route outbound traffic through proxies with strict egress rules.
• In cloud environments, lock down metadata access and use workload identity where possible.

Remote Code Execution (RCE)

What it is

RCE is when an attacker can get your server to execute commands or run code. It’s one of the highest-severity outcomes because it can lead to full server takeover, lateral movement, and data theft.

How RCE happens

RCE is usually not “one bug.” It’s often the result of:

• Unsafe file uploads leading to executable code being run
• Deserialization vulnerabilities (accepting untrusted serialized objects)
• Command injection (passing untrusted input to shell commands)
• Vulnerable dependencies with known exploits
• Template injection (server-side templating engines used unsafely)

How to prevent it

• Avoid passing user input to shell commands; use safe APIs and strict allowlists.
• Treat file uploads as hostile: validate type, store outside executable paths, and scan.
• Patch dependencies quickly and track CVEs affecting your stack.
• Run services with least privilege (non-root containers, restricted permissions).
• Segment networks and use egress controls to limit damage if a compromise occurs.

Read: Best Ways to Update Drivers On Windows PC

How These Attacks Connect in Real Incidents

In practice, attackers chain issues together. A realistic path might look like:

1. Find an SSRF to steal cloud credentials.
2. Use credentials to access storage buckets or secrets.
3. Exploit a weak permission model to escalate.
4. Plant a backdoor or use an unpatched dependency to achieve RCE.

This is why single-point fixes aren’t enough. You need layered defenses.

Practical Security Baselines for Web Apps

If you want a high-impact baseline that prevents most of these issues:

• Use parameterized queries everywhere (SQLi).
• Use escaping-by-default templates and CSP (XSS).
• Use CSRF tokens + SameSite cookies (CSRF).
• Apply strict outbound allowlists and block internal ranges (SSRF).
• Patch aggressively, restrict privileges, and harden runtime environments (RCE).
• Add logging and alerting for unusual patterns (spikes in 4xx/5xx, auth anomalies, unexpected outbound calls).

Final Thoughts

SQLi, XSS, CSRF, SSRF, and RCE are common because they exploit fundamental realities of web apps: they accept input, render output, maintain sessions, talk to other systems, and run on powerful servers. The good news is that defenses are well-known. The challenge is consistency, applying secure defaults everywhere, keeping dependencies updated, and designing systems so that one mistake doesn’t become a breach.