# Chapter 7 — Web Security: CSRF, CORS, XSS, SQLi By the end of this chapter you will: - Configure CORS without weakening security - Defend every endpoint from CSRF correctly - Stop XSS at templating, not at sanitization - Make SQL injection structurally impossible --- ## The why > CSRF, CORS, XSS, and SQLi are the "Big Four" of web security. They've been in the OWASP Top 10 for 20+ years. They still ship in production code every single day — not because they're hard to fix, but because developers don't learn the defenses deeply enough to make them automatic. This chapter makes them automatic. --- ## Core concepts ### SQL Injection (SQLi) — the oldest and still most common SQL injection happens when user input is concatenated into SQL queries. The fix is parameterized queries — always. ```javascript // ❌ VULNERABLE: string concatenation app.get('/users', async (req, res) => { const { search } = req.query; // Attacker input: ' OR '1'='1' -- const result = await db.query(`SELECT * FROM users WHERE name = '${search}'`); // Query becomes: SELECT * FROM users WHERE name = '' OR '1'='1' --' // Returns ALL users. Attacker just dumped your entire user table. }); // ✅ SAFE: parameterized query app.get('/users', async (req, res) => { const { search } = req.query; const result = await db.query('SELECT * FROM users WHERE name = $1', [search]); // Input is treated as a literal string value, not SQL code. }); ``` **Real attack examples:** - `' OR '1'='1' --` — bypass WHERE clause, return all rows - `'; DROP TABLE users; --` — destructive (requires multi-statement support, rare in modern drivers) - `' UNION SELECT email, password FROM admin_users --` — extract data from other tables - `1; WAITFOR DELAY '00:00:05' --` — time-based blind SQLi (extracts data one character at a time by timing responses) **Defense checklist:** 1. ✅ Parameterized queries everywhere (Prisma, Drizzle, `$1`/`?` placeholders) 2. ✅ Never concatenate user input into SQL strings 3. ✅ If you must use dynamic table/column names (rare), whitelist them — never from user input 4. ✅ Least-privilege database user (no DROP TABLE, no pg_read_all_data) 5. ✅ ORM — but verify generated SQL. `$queryRaw` with string interpolation is still SQLi. ### Cross-Site Scripting (XSS) — injecting scripts into other users' browsers XSS happens when user input is rendered as HTML without escaping. Three types: | Type | Attack vector | Example | |------|-------------|---------| | **Stored XSS** | Attacker's input saved to DB, served to all users | Comment field: `` | | **Reflected XSS** | Attacker's input reflected immediately in the response | Search query in URL parameters echoed on page | | **DOM XSS** | Client-side JS reads attacker-controlled data and inserts into DOM unsafely | `element.innerHTML = location.hash.slice(1)` | ```javascript // ❌ VULNERABLE: raw HTML insertion res.send(`

Search results for: ${req.query.q}

`); // Attacker sends: ?q= // Every visitor's cookies get sent to evil.com // ✅ SAFE: escape output // In server-rendered apps, use a templating engine that escapes by default: res.render('search', { query: req.query.q }); // Handlebars/EJS auto-escape // In SPAs, use framework-safe methods: // React:

{userInput}

— auto-escaped // NOT:

``` **Defense:** - Contextual output encoding (HTML context, attribute context, JavaScript context — each needs different escaping) - Content Security Policy (CSP): `Content-Security-Policy: default-src 'self'; script-src 'self'` — blocks inline scripts - HttpOnly cookies: even if XSS succeeds, `document.cookie` returns nothing for sensitive cookies - Sanitize HTML input: use DOMPurify (browser) or `sanitize-html` (Node.js) for rich-text input ### Cross-Site Request Forgery (CSRF) — making users perform actions they didn't intend CSRF tricks a logged-in user's browser into making requests to your API without their knowledge. ``` 1. Alice is logged into bank.com (session cookie set) 2. Alice visits evil.com (or clicks a phishing link) 3. evil.com has:

4. Alice's browser sends the request to bank.com — WITH her session cookie 5. bank.com sees a valid session → processes the transfer ``` **Defense (choose one):** | Method | How | Best for | |--------|-----|----------| | **SameSite cookies** | `Set-Cookie: session=...; SameSite=Lax` — cookie not sent on cross-site POSTs | Modern browsers. Simplest defense. | | **CSRF tokens** | Server generates random token → embedded in form as hidden field → validated on submit | Traditional web apps with forms | | **Custom header** | Require `X-Requested-With: XMLHttpRequest` or `Authorization: Bearer ...` | SPAs and APIs (browsers can't set custom headers cross-origin) | | **Origin/Referer validation** | Check `Origin` header matches your domain | API endpoints | SameSite cookies don't send on cross-site POSTs. Bearer tokens (Authorization header) can't be set by HTML forms — they require JavaScript. Either one makes CSRF structurally impossible for your API. CSRF tokens are only needed if you use traditional cookie-based forms without SameSite. ### Cross-Origin Resource Sharing (CORS) — who can call your API from a browser CORS is NOT a security mechanism. It's a **relaxation** of the browser's same-origin policy. Configuring CORS incorrectly opens your API to cross-origin attacks. ```javascript // ❌ DANGEROUS: allows any origin, with credentials app.use(cors({ origin: true, // Reflects any Origin header (including attacker's) credentials: true, // Allows cookies to be sent cross-origin })); // This effectively disables the same-origin policy. // ✅ SAFE: whitelist specific origins const ALLOWED_ORIGINS = [ 'https://myapp.com', 'https://staging.myapp.com', ]; app.use(cors({ origin: (origin, callback) => { if (!origin || ALLOWED_ORIGINS.includes(origin)) { callback(null, true); } else { callback(new Error('Not allowed by CORS')); } }, credentials: true, methods: ['GET', 'POST', 'PUT', 'DELETE'], allowedHeaders: ['Content-Type', 'Authorization'], })); ``` **CORS rules:** - Never use `origin: '*'` with `credentials: true` — browsers will reject it (and if they don't, it's catastrophic) - Never reflect the `Origin` header blindly (`origin: true`) - Whitelist specific origins. Use a function if you have many. - Set `Access-Control-Allow-Methods` to only the methods your API uses - Set `Access-Control-Max-Age` to cache preflight responses (reduces OPTIONS requests) --- ## Real-world example: The 2018 British Airways Magecart attack Attackers injected 22 lines of JavaScript into British Airways' payment page via a compromised third-party script. The script captured credit card data from the payment form and sent it to `baways.com` (a lookalike domain). 380,000 customers' data was stolen. BA was fined £183 million (later reduced to £20 million). **What would have prevented it:** - **CSP** with strict `script-src` would have blocked the injected script (it came from an unapproved domain) - **Subresource Integrity (SRI)** would have detected the modified third-party script - **Regular third-party script auditing** would have caught the compromise faster --- ## Common mistakes | Mistake | Why it's wrong | What to do instead | |---------|---------------|-------------------| | String interpolation in SQL | SQL injection — attacker can execute arbitrary SQL | Parameterized queries. Always. | | `dangerouslySetInnerHTML` with user input | XSS — attacker can inject scripts | Use DOMPurify to sanitize before rendering | | `cors({ origin: '*' })` with credentials | Allows any website to make authenticated requests as your users | Whitelist specific origins | | No CSP header | XSS exploits have no last line of defense | Add `Content-Security-Policy` header. Start with `default-src 'self'` and loosen as needed. | | Trusting `Referer`/`Origin` for security-critical decisions | Headers can be spoofed (by non-browser clients) or missing | Use as defense-in-depth, not as primary security | | Session cookies without SameSite | CSRF attacks can use the session silently | `SameSite=Lax` minimum. `Strict` for banking. | --- ## Production notes - **CSP in report-only mode first.** Deploy `Content-Security-Policy-Report-Only`, collect violation reports for a week, fix false positives, then enforce. - **Use Helmet.js** for Express apps. It sets security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) with sensible defaults. - **CSRF tokens expire.** Regenerate on login and on timeout. A stolen token should have a limited window. ## Performance notes - **CSP has no performance impact.** It's a header — the browser enforces it on the client. - **CSRF token validation adds negligible overhead** (< 0.1ms for string comparison). - **XSS sanitization (DOMPurify) adds ~1–5ms** per HTML string. Acceptable for user-generated content. ## Security notes - **Defense in depth.** Parameterized queries AND least-privilege DB user AND WAF. CSP AND output encoding AND HttpOnly cookies. No single defense is sufficient. - **Test your defenses.** Run OWASP ZAP or Burp Suite against your staging environment. Automated scanners catch the obvious issues. Manual testing catches the rest. --- ## Exercises ### Beginner 1. Write a vulnerable Express endpoint with SQL injection (string interpolation). Exploit it to return all users. Then fix it with parameterized queries. 2. Set up CORS on an Express API. Test cross-origin requests from a different port. Observe the preflight OPTIONS request and the CORS headers in the response. ### Intermediate 1. Implement CSRF token protection: generate a token, embed it in a form, validate it on the server. Test that a request without the token is rejected. 2. Write a stored XSS attack against a vulnerable comment system (raw HTML rendering). Then fix it with output escaping and CSP headers. ### Advanced 1. Deploy a Content Security Policy in report-only mode. Collect violation reports for 24 hours. Analyze what scripts/styles are being blocked. Iterate on the policy until zero violations. Then enforce. 2. Implement a WAF-like middleware that detects and blocks common attack patterns (SQLi, XSS) using regex or a library like `sqlstring`. Log blocked requests for monitoring. --- ## Interview questions ### Beginner 1. **What is SQL injection and how do you prevent it?** User input interpreted as SQL code. Prevent with parameterized queries — never concatenate user input into SQL strings. 2. **What is XSS and what are the three types?** Cross-Site Scripting — injecting malicious scripts into web pages. Stored (saved to DB, served to all users), Reflected (immediately echoed in response), DOM-based (client-side JavaScript manipulates DOM unsafely). 3. **What does CORS do?** Allows browsers to make cross-origin requests that the same-origin policy would normally block. It's a relaxation mechanism, not a security mechanism. ### Senior 4. **Explain how CSRF works and name three defenses.** An attacker tricks a user's browser into making an unwanted request to a site where the user is authenticated. Defenses: SameSite cookies (cookie not sent cross-site), CSRF tokens (server validates a token embedded in the request), custom headers (browsers can't set `Authorization` or custom headers cross-origin without a preflight that the attacker can't control). 5. **Why shouldn't you rely solely on CORS for API security?** CORS is enforced by the browser, not the server. A non-browser client (curl, Postman, a script) can make any request to your API regardless of CORS settings. CORS is a browser restriction, not a server-side security control. Always authenticate and authorize API requests. 6. **What is Content Security Policy and how does it mitigate XSS?** CSP is an HTTP header that tells the browser which sources of scripts, styles, images, etc. are allowed. `script-src 'self'` means only scripts from your own domain can execute — injected inline scripts (``) are blocked. CSP makes XSS exploitation significantly harder, even if an injection point exists. --- ## Summary SQL injection: parameterized queries. Always. XSS: output encoding + CSP + HttpOnly cookies. CSRF: SameSite cookies or CSRF tokens or Bearer tokens (pick one, be consistent). CORS: whitelist origins, never `origin: '*'` with credentials. These four vulnerabilities have existed for 20+ years because they require constant vigilance. Make the defenses automatic — linters, WAFs, CSP headers, parameterized query requirements in code review. --- ## Quick recall - SQLi: parameterized queries ($1, ?). Never string interpolation. - XSS: escape output, CSP header, HttpOnly cookies, DOMPurify for rich text. - CSRF: SameSite=Lax cookies OR CSRF tokens OR Bearer tokens with custom headers. - CORS: whitelist origins, never `*` with credentials. Not a server-side security control. - Defense in depth: no single mechanism is enough. Layer them. - Test: OWASP ZAP, Burp Suite, automated scanners in CI. --- ## Quiz 1. What's the single most effective defense against SQL injection? **Parameterized queries — never concatenating user input into SQL strings.** 2. What are the three types of XSS? **Stored, Reflected, DOM-based.** 3. How does SameSite=Lax prevent CSRF? **The cookie is not sent on cross-site POST requests (form submissions, AJAX) — the attacker's site can't trigger authenticated actions.** 4. Why isn't CORS a server-side security mechanism? **CORS is enforced by the browser. Non-browser clients (curl, scripts) ignore it completely. Always authenticate/authorize API requests.** 5. What does CSP do? **Tells the browser which sources of content (scripts, styles) are allowed. Blocks injected scripts even if XSS exists.** 6. Why shouldn't you use `cors({ origin: '*' })` with `credentials: true`? **Allows any website to make authenticated requests as your users. Browsers will reject this combination, but misconfigured proxies might not.** 7. What's the difference between hashing and encryption? **Hashing is one-way (irreversible). Encryption is two-way (can be decrypted with a key). Hash passwords. Encrypt data you need to read back.**

Chapter 7 — Web Security: CSRF, CORS, XSS, SQLi

Part of L3