Applied · Module 3
Web security in practice
Most breaches start with what is exposed, not with exotic zero days.
Previously
Identity and access control
Authentication answers who you are.
This module
Web security in practice
Most breaches start with what is exposed, not with exotic zero days.
Next
API and service security
When you review an API, focus on these ideas.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Operating systems run services, services open ports, and apps expose inputs.
What you will be able to do
- 1 Explain what attack surface means in a web app
- 2 Spot quiet exposure such as debug routes, headers, and forgotten subdomains
- 3 Explain why server side validation and access control matter
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Validation gaps. One unchecked field is enough. Attackers look for the single weak edge.
- Missing rate limits. Without rate limits, brute force and abuse become cheap.
Operating systems run services, services open ports, and apps expose inputs. The attack surface grows with every feature and every default left unchanged.
In simple terms, attack surface is everything someone can touch. If they can touch it, they can try to break it, confuse it, or use it in a way you did not plan for.
In the real world, what I actually do is inventory exposure. Endpoints, admin panels, file uploads, third party scripts, public buckets, test environments, and forgotten subdomains. Then I ask which of those touches sensitive data or powerful actions. That is where I look first.
Common failure classes repeat and include injection, broken access control, unsafe defaults, and vulnerability through a reachable entry point. These are not rare. They are the same few mistakes showing up in different clothes.
How it fails. A feature gets shipped behind a toggle, then the toggle is left on in production. A debug route leaks stack traces. An admin page is "temporary" and ends up indexed by a crawler. A dependency is added and nobody reviews what it loads in the browser.
How to do it well. Reduce what is exposed, secure what must be exposed, and make sure every exposed input has validation, authentication where appropriate, and monitoring. The trade off is speed. More exposure makes development easier until the day it makes incident response harder.
Before you use the tool, treat each toggle as a real decision. When you turn something on, ask two questions. What new input did I create, and what new assumption did I just make.
After you use the tool, look for the "quiet" exposure. A lot of damage comes from boring things like default ports, metadata, admin routes, and third party scripts. The common mistake is focusing only on big obvious inputs and missing the small ones that are easiest to probe.
Mental model
Input to database flow
Most web vulnerabilities are untrusted input reaching a sensitive operation.
-
1
Browser
-
2
Server
-
3
Validate
-
4
Database
Assumptions to keep in mind
- Inputs are untrusted. Assume every field can be malicious or broken. Validation is part of security.
- Sensitive operations are gated. Authentication is not enough. Authorise every sensitive action.
Failure modes to notice
- Validation gaps. One unchecked field is enough. Attackers look for the single weak edge.
- Missing rate limits. Without rate limits, brute force and abuse become cheap.
Key terms
- injection
- untrusted input treated as instructions
- vulnerability
- a weakness that can be exploited
Check yourself
Quick check. Web security
0 of 6 opened
What expands attack surface the fastest
New features or services that add inputs, ports, or integrations without controls.
Scenario. A search box lets users type anything and the results suddenly include other users' records. What class of failure might this be
Often injection or broken access control. The key is that untrusted input changed what the system executed or returned.
Scenario. A developer leaves a debug route enabled in production because it is convenient. Why is that dangerous
It can leak stack traces, config, or sensitive data. It also becomes an extra entry point attackers can probe.
How does metadata leak
Banners, headers, error messages, and timing can reveal versions or behaviour even if content is encrypted.
Scenario. Where should validation live if you want it to actually protect you
Server-side at every untrusted input, before data reaches interpreters or storage. UI checks are helpful but not sufficient.
Why map trust boundaries when reviewing attack surface
They show where assumptions change and where extra checks or isolation are needed.
Artefact and reflection
Artefact
A short attack surface inventory for one small app
Reflection
Where in your work would explain what attack surface means in a web app change a decision, and what evidence would make you trust that change?
Optional practice
Toggle features on and off and see how ports, metadata and assumptions expand or shrink your exposure.