Start from zero: what web security actually is
Web security is designing so a hostile stranger can send anything and your system still holds. This is the from-zero map and the eight words the security track assumes you already know.
Someone on the internet is already sending requests to your app right now. Not just users — crawlers, scanners, bots, and sometimes people who are deliberately trying to break things. They will send strings that look like SQL. They will claim to be an admin. They will submit a form a thousand times a second. They will embed JavaScript inside a username field. You cannot stop them from trying. What you can do is design your system so that none of it matters — so that bad input goes nowhere, stolen tokens unlock nothing, and leaked data reveals nothing readable. This lesson is the map before the climb.
The one idea security is built on
On the internet you cannot control who connects to you. A request might come from a real user, a broken client, an automated scanner, or an attacker. The core assumption of web security is: treat every input as potentially hostile until you have verified otherwise. That sounds paranoid. It is also the only design principle that holds at scale. Every vulnerability you will study in this track — from SQL injection to session hijacking — exists because something trusted input it should not have.
Everything else is machinery that implements this one idea: design so that compromise of any single piece cannot compromise everything.
The eight words the rest of the track assumes
If you have ever seen a login form bypass, a leaked API key in a public repo, or a session that never expired — you were watching exactly these concepts fail. The senior lessons that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Authentication | Proving who you are — confirming the user is who they claim to be. | So the system knows which person is making a request before doing anything on their behalf. |
| Authorization | Deciding what you may do — checking that the confirmed user is allowed to take this action. | So knowing who someone is does not automatically grant access to everything. |
| Threat / Attacker | Any actor (person, bot, or program) trying to make the system behave in unintended ways. | Named explicitly so security design can reason about motive, capability, and likely attack paths. |
| Input validation | Checking that data from outside the system matches the shape and range you expect before using it. | So malformed or malicious data is rejected at the boundary, not passed deeper where it can cause harm. |
| Secret | A password, API key, or cryptographic key the system needs but must never expose. | So credentials stay out of source code, logs, and error messages where attackers could find them. |
| Encryption in transit / at rest | Scrambling data with a key so only the holder of the matching key can read it — while moving (TLS) or while stored (database / disk encryption). | So intercepted traffic or a stolen disk reveals nothing useful without the key. |
| Session / Token | A short-lived credential issued after authentication that the client sends with every request so the server can re-identify them without re-asking for a password. | So HTTP’s stateless nature does not force users to log in on every click. |
| Trust boundary | A line between two parts of the system where the level of trust changes — such as the edge between the public internet and your server, or between user input and a database query. | So security checks happen at every boundary, not assumed somewhere upstream. |
How they fit together
Read in order, the words tell one story: you first authenticate the user to find out who they are, then authorize them to check what they may do. You never trust any input that crosses a trust boundary until it has been validated. Secrets are kept out of reach so leaked code or logs give an attacker nothing useful. Data is encrypted in transit so network interception is useless, and encrypted at rest so a stolen disk is unreadable. A session or token carries identity forward without re-authentication on every request, and it expires so stolen tokens have a limited window of harm.
▸Why this works
Two common misunderstandings are worth naming now. First: hashing is not encryption. Hashing (used for passwords) is a one-way transform — the original cannot be recovered even with the key. Encryption is two-way: data can be decrypted by whoever holds the key. They solve different problems. Second: input validation is necessary but not sufficient. It stops a lot, but an attacker who controls the application layer or the database directly bypasses it. Defence in depth — multiple overlapping controls — is why the track has many units, not one.
What is the difference between authentication and authorization?
Order the security checks a server performs when it receives a request from a user clicking 'delete my account':
- 1 Validate the session token to confirm who sent the request (authentication)
- 2 Check that this user is allowed to delete an account — their own, specifically (authorization)
- 3 Validate and sanitize all input data crossing the trust boundary
- 4 Perform the action, keeping secrets and encrypted data out of any error responses
- 01What is the single core assumption of web security, and why?
- 02Name the eight foundational words, giving what each is and why it exists.
Web security is one idea with many controls hung off it: design so a hostile stranger can send anything and the system still holds. The identity half is authentication (who you are) followed by authorization (what you may do) — knowing who someone is does not grant access to everything. The input half is validation at every trust boundary, because every class of injection attack exists where something trusted data it should not have. The data half is keeping secrets out of code and logs, encrypting data in transit with TLS so interception is useless, and encrypting data at rest so a stolen disk reveals nothing. Sessions and tokens carry identity between stateless requests, and they expire so the damage window of a stolen token is bounded. None of these controls is sufficient alone — defence in depth is why this track has many units, not one. Now when you read a post-mortem or review a pull request, you will recognize which of these eight words was missing — and know exactly where to look. Next: Unit 01, the OWASP Top 10 and the most common ways these rules get broken in practice.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.