Secure › Module 3 › Lesson 2
Allowlists
Prefer allowlists over denylists — validate shape on YOUR toy app inputs.
Visual · allowlists
Allowlist validation literacy. $MY_REPO only. Original Cyberlium.
Opening
Denylist 'no script tags' loses. Allowlist 'only these enum values' wins — in your repo first.
Allowlist validation accepts only known-good patterns: regex for email shape, enum for role field, max length on username. Denylists block known-bad strings and fail on novel attacks. Cyberlium teaches allowlist validators on $TOY_APP in $MY_REPO — not crafting bypass payloads against live shops. You will NOT publish allowlist bypass cheats aimed at stranger carts or run sqlmap to 'test' denylist failures on dorm projects. Next: Injection Shapes.
1. Known-good beats known-bad
Role field: allow ['user','admin'] not 'block SQL keywords.' Country code: allow ISO list not 'block union select.' File upload: allow image/jpeg with size cap not 'block.exe only.'
Implement one allowlist validator in $MY_REPO and unit-test accepted vs rejected cases locally.
Command guide
Try these commands — Known-good beats known-bad
═══ LINUX / BASH (Network & Reconnaissance Audit) ═══
Scan target host for open ports and service version signatures
Command — copy this
nmap -sS -sV -p 80,443,8080 -Pn ${LAB_HOST:-127.0.0.1}DNS and WHOIS reconnaissance on authorized domain
Command — copy this
dig +short A target.local dig +short MX target.local whois target.local 2>/dev/null | grep -iE "(Registrar|Creation Date|Name Server)" | head -6
Inspect HTTP headers for technology stack fingerprinting
Command — copy this
curl -s -I "http://${LAB_HOST:-127.0.0.1}:8080" | grep -iE "(Server|X-Powered-By|Set-Cookie|Content-Security-Policy)"Primary tools to practice this lesson: python3. Reference sites: Input validation (https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html); CWE-20 (https://cwe.mitre.org/data/definitions/20.html). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Validation belongs server-side
Client-side checks are UX; server-side allowlists are security. Never trust browser validation alone on boundaries you control in $TOY_APP.
Defenders log validation failures as signal — you add structured reject reasons without echoing attack payloads to logs.
3. No stranger bypass homework
Finding allowlist bypass on live e-commerce is unauthorized testing — out of scope. Lab stays on $MY_REPO toy endpoints.
Ship: one allowlist validator + two unit tests. Next: Injection Shapes.
4. What you ship: allowlist validator for $TOY_APP
One allowlist rule with tests (pass/fail cases). Server-side in $MY_REPO. chmod 600 note.
5. What you record before the next lesson
Date. Allowlist field and rule. Test cases noted. File t17-m03-l02-allowlists.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
Denylist only 'script' on live review forms. sqlmap classmate API because allowlist 'might fail.'
Right
Implement allowlist validator on $TOY_APP. Next: Injection Shapes.
Mission: allowlist validator
1) Pick one field (role, email, country). 2) Write allowlist validation server-side in $MY_REPO. 3) Add two unit tests: accept good, reject bad. Never test allowlists on stranger production.
Stuck? Ask Cyberlium AI Mentor
Enum roles beat regex alone for small fixed sets.
Knowledge Check
APPLY: Allowlist validation means:
Multiple choice
Knowledge Check
APPLY: True or False: Server-side validation can be skipped if the SPA validates input.
True or False
Knowledge Check
APPLY: sqlmap on classmate deploy to 'test allowlists':
Multiple choice