Common Vulnerabilities

SQL injection

When you glue user input directly into a SQL string, an attacker can break out and run their own queries:

// VULNERABLE — string concatenation
query("SELECT * FROM users WHERE name = '" + input + "'")

// Attacker enters:  alice'--
// Becomes:  SELECT * FROM users WHERE name = 'alice'--'
// (the -- comments out the rest, bypassing the password check)

Fix: use parameterized queries. The database sends the SQL structure and the values separately, so input can never alter the query's logic:

query("SELECT * FROM users WHERE name = ?", [input])

Cross-site scripting (XSS)

XSS is injecting hostile HTML or JavaScript into a page viewed by other users — for example, posting a comment containing <script> that runs in every visitor's browser.

• Stored XSS — the payload is saved (e.g. in a comment) and served to others.
• Reflected XSS — the payload comes from a URL parameter echoed back.

Fix: output encoding. Escape user-supplied data before rendering it, so <script> becomes harmless text. Modern frameworks (React, Vue) escape by default.

The rule: never insert raw user input into HTML. Treat all input as hostile until encoded.

Cross-site request forgery (CSRF)

CSRF tricks a logged-in user's browser into making a request to a site where they're authenticated — like a forged form that transfers money. The browser happily attaches the session cookie, so the request looks legit.

Fix: CSRF tokens. The server embeds a secret token in each form and rejects requests that don't include it. An attacker's site can't read the token (same-origin policy), so its forged requests fail.