Web application security: Common Vulnerabilities and prevent techniques - The complete developer guide (2026)

INTRODUCTION
Why web appilication security matters in 2026

Every line of code you ship is a potencial attack surface. web appilications today handle financial transactions, personal health data, government records, and private communications — making them the prime target of cybercriminals, nation-state actors, and opportunistic bots alike. 

Despite decades of security research and widely guidance (OWASP, NIST, ISO 27001), the same categories of vulnerabilities appear year after year in real world breaches. This guide is built for developers, security engineers, and CTOs who want a practinioner-level understanding of what these vulnerabilities are, why they work, and how to stop them — with real code example and actionable prevention strategies

VULNERABILITY #1
SQL Injection —  The silent data killer

SQL injection (SQLi) has been the #1 or #2 most exploited for over 20 years. It occurs when user-supplied input in concatented directly into a SQL query, allowing an attacker an to manipulate the query logic itself.

SQL Injection (SQLi) Critical
Attacker controls database queries by injecting malicious SQL syntax through input fields, URL params, or HTTP headers.

Vulnerable code (PHP)
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
//  Input: admin' OR '1'='1
//   Resulting query: SELECT * FROM users WHERE username = 'admin' OR '1'='1'
Safe code — parameterized query (PHP PDO)
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$_GET['user']]);

Prevention techniques :

1. USE prepared statement — never concatenate user into SQL. 
2. USE a ORM (Sequelize, Hibernate, SQLAlchemy) — they handle parameterization by default.
3. Apply least-privilage DB accounts — your app DB user should not have DROP or ALTER rights.
4. Enable a WAF with SQLi rule as a seciundary defense layer. 

VULNERABILITY #2
Cross-Site Scripting (XSS) — Scripts that shouldn't be there 

XSS lets attackers inject malicious JavaScript into pages viewed by other users. There are three types: Reflected (server echoes back untrusted input),  Stored (malicious script saved to DB and served at all uders), and DOM-based (client side script writes attacker-controlled data into DOM).

Cross-Site Scripting (XSS) Critical
Injected scripts execute in the victim's browser — enabling session hijacking, credential theft, keylogging, and malware delivery.

Vulnerable (React — dangerous direct insertion)
//   NEVER do this

1. Output encode all user data before rendering in HTML, CSS, JS, or URL contexts.
2. Set Content-Security-Policy (CSP) headers — restrict which scripts can execute.
3. Use HttpOnly cookies — prevent JS from reading session tokens even if XSS occurs.
4. Use DOMPurify when rendering HTML is unavoidable (eg: rich text editor).

VULNERABILITY #3
Broken Authentication — The unlocked front door 

Authentication flaws let acttackers assume other users' identities. This includes week passwords, credentials stuffing, insecure session management, missing MFA, and poorly implemented "forgot password" flows.

Prevention techniques : 

1. Hash password with bycrpt, scrypt, or Argon2 — never MD5, SHA-1, or unsalted hashes.
2. Enforce MFA for all sensitive accounts. U se TOTP or passkey.
3. Implement account lockout / rate limiting on login endpoints.
4. Regenerate session IDs on privilage elevation after login.
5. Use short-lived JWTs with refresh token rotation, never long-lived tokens in local Storage. 

//  Bcrypt hashing (Node.js)
const bcrypt = require('bcrypt');
const hash = await bcrypt.hash(password, 12); // cost factor 12+
const valid = await bcrypt.compare(inputPassword, hash);

VULNERABILITY #4
Cross-Site Request Forgery (CSRF) — Forged request in disguise

CSRF tricks an authenticated user's browser into making unintended requests to your application. Because the request carries the victim's cookies, your server can't ytelll the diffrence between a legitimate and a forged request — without explicit CSRF protections.

Prevention techniques : 

1. Synchronizer Token Pattern — include a secret CSRF token in every state-changing form and validate it server -side.
2. SameSite=Strict or Lax cookies —  modern browsers block cross-origin cookies sending with attribute.
3. Varify Origin / Referer headers on sensitive endpoint as a secondary check.
4. Require re-authentication for high-stakes actions (transfers, email changes).

VULNERABILITY #4
IDOR — Insecure Direct Object Reference

IDOR occures when your appilication exposes internal object references (like database IDs) in URLs or API parameters, and fails to check whether the requesting user is actually authorized to access that object.

//   Vulnerable API endpoint
GET /api/invoices/1042 ← user just changes ID to access any invoice

//   Safe server-side check (Node.js / Express)
const invoice = await Invoice.findById(req.params.id);
if (!invoice || invoice.userId !== req.user.id) {
  return res.status(403).json({ error: 'Forbidden' });
}

Prevention techniques : 

1. Always authorize, not authenticate — check ownership/permission for every object access.
2. Use UUIDs instead of sequence IDs to reduce emmeration risk (defence in depth — not a substitute for authentication).
3. Implement role-based access control (RBAC) or attribute-based control (ABAC) at the data layer.

Conclusion

Web application security is not a one-time task — it is an ongoing discipline. The vulnerabilities covered in this guide — SQL Injection, XSS, Broken Authentication, CSRF, IDOR, Security Misconfiguration, and Sensitive Data Exposure — are not theoretical. They drive real breaches, real fines, and real loss of user trust every single day.