XSS, CSRF & Injection — Series 2

Preview — 3 of 10 questions

If an attacker submits username = "' OR '1'='1", what happens?

javascript

const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
db.query(query);

AThis is safe, because JavaScript's template literals automatically escape special characters like quotes

BSQL injection only works against MySQL — this specific attack wouldn't work on PostgreSQL or other databases

CThe injected ' OR '1'='1 turns the WHERE clause into an always-true condition (username = '' OR '1'='1' AND password = '...'), potentially returning every row in the users table — bypassing authentication entirely, without knowing any valid password

DThe query fails with a syntax error and returns no rows, so this input is harmless

An authenticated user can view their own invoice at /api/invoices/1234. By simply changing the URL to /api/invoices/1235, theyre able to view a *different* users invoice. Whats this vulnerability called, and whats the fix?

javascript

GET /api/invoices/1234
GET /api/invoices/1235

ACross-Site Scripting (XSS) — the fix is to sanitize the invoice ID before rendering it in the response

BSQL Injection — the fix is to use parameterized queries for the ID lookup

CCross-Site Request Forgery (CSRF) — the fix is to add a CSRF token to the request

DInsecure Direct Object Reference (IDOR) — the endpoint fetches an invoice by ID without ever checking whether the requesting user actually owns (or is otherwise authorized to access) that specific invoice; the fix is to add an authorization check on every object-fetching endpoint, confirming the resource belongs to the authenticated user before returning it

This endpoint lets users submit a URL to generate a link preview. What's the security risk?

javascript

app.post('/fetch-preview', async (req, res) => {
  const { url } = req.body;
  const response = await fetch(url);
  res.send(await response.text());
});

AServer-Side Request Forgery (SSRF): an attacker can submit an internal-only URL (e.g., a cloud metadata endpoint, or an internal service like a Redis instance on localhost) and the server — which typically has network access the attacker doesn't have directly — makes that request on the attacker's behalf, potentially leaking cloud credentials, internal secrets, or reaching services that were never meant to be internet-facing

BThis is safe — fetch can only reach public internet URLs, never internal network addresses

CThe only real risk is a slow response if the submitted URL points to an unusually large file

DThis endpoint is only exploitable if the server happens to be hosted on AWS specifically

Answer all 10 questions (7 more), see explanations for every answer, and track your score.