6.What Could Someone Type Here?

The Problem in Real Life

Trusting What Users Type vs. Treating Every Input as a Stranger

Secure Coding: Validation, SQL Injection, XSS and CSRF

• Secure coding basics — every input is untrusted: treat everything that comes from outside — form fields, URL parameters, headers, cookies, uploaded files, even data from other APIs — as possibly hostile. The browser's checks are only for convenience: attackers skip the browser entirely and send requests directly (Act 12).
• Input validation — the bouncer (Act 08): on the server, check every input against what it should be: type (a number), length (1–20 characters), format (letters and digits only), range (1–6 tickets). Prefer allow-lists ("only these characters") over block-lists ("not these"). Reject anything else with a clear error. Validation stops a lot — but it's not enough on its own, because some valid text is still dangerous in the wrong place.
• SQL injection — data that becomes a database command: if code glues user input into an SQL string (Act 13), the input can change the command. With venue = ' OR 1=1 --, the query WHERE venue_id = '' OR 1=1 --' becomes "where venue is empty, or where 1 equals 1" — which is true for every row — and -- turns the rest into a comment. The fix is parameterised queries (also called prepared statements): the SQL and the values are sent separately, so the database always treats the value as just data, never as part of the command. ORMs and query builders do this for you.
• XSS (cross-site scripting) — text that becomes code in other people's browsers: if a site shows user-written text as raw HTML, an attacker can write <script>...</script> into, say, an event review. Every fan who views that page then runs the attacker's script on BlueTicket's site — it could steal data from the page or act as the fan. The fix is output escaping: turn < into < and so on before showing user text, so the browser displays it instead of running it. Modern frameworks like React escape by default — danger comes from bypassing that (dangerouslySetInnerHTML). A Content Security Policy header adds a second wall, and HttpOnly cookies stop scripts reading the session (chapter three).
• CSRF (cross-site request forgery) — a forged letter with your signature: while a fan is logged in to BlueTicket, they visit an evil site. That site secretly makes their browser send a request to BlueTicket — "transfer my tickets to this account" — and the browser automatically attaches the fan's cookie. BlueTicket sees a valid session and obeys. The fixes: SameSite cookies (the browser doesn't send them on most requests started by other sites), CSRF tokens (a secret value in each real form that the evil site can't know), and never changing anything with a GET request (Act 12).

// DANGEROUS: user input glued into the SQL text
const sql = "SELECT * FROM sales WHERE venue_id = '" + req.query.venue + "'";
// venue = ' OR 1=1 --   becomes:
// SELECT * FROM sales WHERE venue_id = '' OR 1=1 --'      -> every venue's sales!

// SAFE: parameterised query — the value is sent separately, always as data
const result = await db.query(
  "SELECT * FROM sales WHERE venue_id = $1",
  [req.query.venue]
);

A review typed by an attacker:   <script>stealData()</script>
What the escaped page contains:  &lt;script&gt;stealData()&lt;/script&gt;
What fans see on screen:         <script>stealData()</script>   (just text — nothing runs)