Secure › Module 3 › Lesson 1
Trust Boundaries
Mark where data crosses from untrusted to trusted — in YOUR $TOY_APP only.
Visual · trust_boundaries
Trust boundary literacy. $MY_REPO only. Original Cyberlium.
Opening
Every HTTP request crosses a boundary. Your job is to greet it with validation — on code you own.
A trust boundary is where data moves from a zone you do not control (browser, mobile client, third-party webhook) to a zone you do (your API, database). Secure code validates, authenticates, and authorizes at those lines. Cyberlium teaches boundary mapping on $TOY_APP in $MY_REPO — not probing stranger APIs to 'find boundaries.' You will NOT map trust boundaries by fuzzing a live shop cart or replaying webhooks against classmate deploys. Next: Allowlists.
1. Untrusted until validated
Clients lie. Headers, JSON bodies, query strings, and file uploads are untrusted at the server boundary. Validate type, length, format, and authorization before business logic runs.
On $MY_REPO, list every entry point: POST /login, GET /profile?id=, file upload route. Mark each as boundary crossing.
Command guide
Try these commands — Untrusted until validated
═══ TOOLS & WEBSITES ═══ Browse / read these (authorized learning only — stay in YOUR lab / program scope)
Input Validation Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
═══ INSTALL ═══
Linux (Debian/Ubuntu):
Command — copy this
sudo apt install python3
macOS:
Command — copy this
brew install python3
Windows: Download https://python.org/downloads/
═══ LINUX / macOS ═══
Command — copy this
mkdir -p "$HOME/cyberlium-lab/t17-toy"
printf 'x=input("name")
print(x)
' > "$HOME/cyberlium-lab/t17-toy/bad_input.py"
grep -n 'input(' "$HOME/cyberlium-lab/t17-toy/bad_input.py"
python3 -m py_compile "$HOME/cyberlium-lab/t17-toy/bad_input.py"Primary tools to practice this lesson: python3, grep. Reference sites: Input Validation Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Inside vs outside
Outside: user input, external APIs you call. Inside: database writes, internal admin functions. Code between them is the gate — middleware, validators, auth checks.
Defenders monitor anomalous crossing (oversized payloads, wrong Content-Type). You practice naming gates before writing exploit strings.
3. Lab boundary
Draw boundaries for $TOY_APP only. Optional: add one validator function at a named boundary in $MY_REPO.
Ship: boundary list with entry points. Next: Allowlists.
4. What you ship: trust boundary list for $TOY_APP
List entry points and boundary crossings. Optional one validator in $MY_REPO. No stranger API probing. chmod 600.
5. What you record before the next lesson
Date. Boundary list for $TOY_APP. File t17-m03-l01-trust-boundaries.txt chmod 600.
6. Wrong vs right: stranger apps vs YOUR repo
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
Wrong
Fuzz stranger API to 'discover boundaries.' Skip validation because 'clients are nice.'
Right
Map boundaries on $TOY_APP. Next: Allowlists.
Mission: trust boundary inventory
1) List three entry points in $TOY_APP. 2) Mark untrusted → trusted direction. 3) Optional one validator stub in $MY_REPO. Never probe stranger APIs for boundaries.
Stuck? Ask Cyberlium AI Mentor
POST body and query params are both boundaries — validate both.
Knowledge Check
APPLY: Trust boundary literacy on Cyberlium uses:
Multiple choice
Knowledge Check
APPLY: True or False: Server code should treat all client input as untrusted at the boundary.
True or False
Knowledge Check
APPLY: Validation at a trust boundary primarily:
Multiple choice