Backend · core

Web Security Basics

XSS, CSRF, SQL injection, and CORS — the injection and confused-deputy bugs that keep recurring.

backendsecurity

Mental model

Almost every one of these is the same bug: data crossing into a place where it is interpreted as code or as authority. Injection (SQLi, XSS) is untrusted input reaching an interpreter, and the fix is never escaping-by-hand but parameterisation and contextual output encoding. CSRF is different in kind — a confused deputy, where the browser helpfully attaches your cookies to a request your site did not initiate, which is why the defence is an unguessable token or SameSite rather than validation. CORS is not a defence at all; it relaxes the same-origin policy, so a permissive CORS header removes protection rather than adding it.

How to study Web Security Basics

Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use OWASP Cheat Sheet — Cross-Site Request Forgery Prevention, OWASP Cheat Sheet — SQL Injection Prevention to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.

Next, compare Web Security Basics with API Design, Security & Isolation Boundaries. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Parameterise instead of escaping and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.

Proof of understanding

Explain the mechanism from first principles and identify the state it reads or changes.
Give one situation where the concept is the right choice and one where it is not.
Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.

Where it matters

The OWASP categories that dominate real breaches, and the review checklist for any endpoint that takes user input.

Common mistakes

Treating CORS as a security control — it grants access, it does not restrict it
Escaping output once globally instead of per context; HTML, attribute, URL and JS contexts need different encodings
Blocklisting dangerous input instead of parameterising the query
Storing session tokens in localStorage, which is readable by any XSS you ever ship

Learn from primary sources

Practice and explain it back

Parameterise instead of escaping

Implement buildQuery(table, filters) returning { text, values }: a parameterised SQL string using $1, $2 … placeholders in order, plus the values array. Column names come from a fixed ALLOWED set — reject anything else by throwing. Never interpolate a value into the string.

Expected evidence: buildQuery('users', {name:'ann', age:30}) -> { text: 'SELECT * FROM users WHERE name = $1 AND age = $2', values: ['ann', 30] }

Open the interactive drill →

Review prompts

A reviewer says 'we set CORS headers, so the API is protected from other sites.' Why is that backwards, and what actually defends the endpoint?