Web Application Security 101: Preventing the OWASP Top 10 Vulnerabilities

The Modern Security Landscape

Web applications are continuously scanned by automated botnets and malicious actors. Whether you are developing an e-commerce platform, banking portal, or e-learning LMS, understanding defensive software engineering is mandatory for every developer.

1. SQL Injection (SQLi)

**The Vulnerability**: Concatenating raw user input directly into SQL strings allows attackers to execute arbitrary database queries, extract private customer records, or drop entire tables.

```javascript // VULNERABLE CODE - NEVER DO THIS: const query = "SELECT * FROM users WHERE email = '" + req.body.email + "'"; ```

**The Defense**: Always use Parameterized Queries or Prepared Statements. Modern query builders and ORMs (such as pg, Prisma, or TypeORM) parameterize values automatically:

```javascript // SECURE CODE: const query = "SELECT * FROM users WHERE email = $1"; const result = await pool.query(query, [req.body.email]); ```

2. Cross-Site Scripting (XSS)

**The Vulnerability**: Attackers inject malicious JavaScript code into your web application that executes within the browser sessions of other legitimate users, stealing session tokens and cookies.

**Types of XSS**: - **Stored XSS**: Malicious script is saved in the database (e.g., in a forum post or profile bio) and executed whenever someone views the page. - **Reflected XSS**: Malicious payload is reflected off a URL query parameter into the HTML output.

**The Defense**: - React automatically escapes string values rendered in JSX. Never use `dangerouslySetInnerHTML` with unescaped, untrusted user inputs. - Sanitize HTML inputs using libraries like `DOMPurify`. - Implement a strict **Content Security Policy (CSP)** HTTP header restricting script execution only to trusted origin domains.

3. Cross-Site Request Forgery (CSRF)

**The Vulnerability**: A malicious third-party site tricks an authenticated user's browser into sending an unwanted HTTP request to your application (such as transferring money or changing passwords).

**The Defense**: - Store authentication tokens in cookies with `SameSite=Lax` or `SameSite=Strict`. - Use anti-CSRF challenge tokens for state-changing operations (`POST, PUT, DELETE`).

4. Broken Authentication and Session Management

• Never store passwords in plain text or with outdated hashing algorithms like MD5 or SHA1.
• Always hash passwords using **Argon2id** or **bcrypt** with a salt round factor of 10 or higher.
• Enforce Multi-Factor Authentication (MFA) via TOTP (Time-based One-Time Password) apps for administrative and elevated roles.
• Automatically invalidate server-side sessions on password change or logout.