The App Is the Attack Surface

A web server answers HTTP. A web application interprets meaning: this POST creates a note for this user; this GET returns an invoice if the session may see it; this cookie is a session id, not a role you honor from a hidden field. Hardening Apache or nginx (Module 13) does not fix a handler that trusts the client. Listing a directory is a server misconfig. Letting user 12 fetch user 13’s object because the URL changed is an application access-control failure. You need both pictures. This module stays on the application picture. The only hosts in play later are an app YOU wrote, a local demo YOU started, or — after Lesson 2 — a bounty asset whose policy YOU actually read. A public website is still someone else’s computer even when it has a login form.

Write the legal sentence before you write a URL list: original Cyberlium teaching mapped to the CEH v13 web-applications domain — not official EC-Council training, not a cert, not exam dumps. A cert acronym in a blog title is not a warrant. Skill does not create consent. “The site is on the internet” is not RoE. Module 1 still wins. For this lesson the artifact is definitions, not traffic at a stranger.

cat >> "$NOTES" << 'EOF'
server: bind, TLS, listing, banners, patches
app: routes and logic that decide who can do what
EOF

Input is every byte the app did not author: query strings, JSON bodies, multipart files, headers (including cookies), path segments. Anything the client can set is input. Validation belongs on the server. Client-side checks are a convenience, not a control. Authentication is the act of establishing identity — password, MFA, magic link, SSO. A login page is not “the app is safe”; it is one door. Session is the reusable token after login: a cookie, a bearer token, a server-side id. Module 11 already named cookies, HTTPS, and HttpOnly as defense — still no hijack proof-of-concept here. Access control (authorization) is the decision after identity: may this principal read this object, call this admin route, change this row. Hiding a URL is not access control. Checking a role in JavaScript is not access control. The server must decide.

Keep a useful failure in mind: a classmate says the CEH web-app domain means “fire Burp at whatever is in the search bar.” Mapping lanes is literacy. Aiming a scanner at a host you do not own is unauthorized testing. Lesson 4 maps routes on YOUR project or a localhost demo. Topic 10 is where Cyberlium goes deep on injection and XSS labs. If a sentence would help someone exploit a shop they do not own, it does not belong in your notes.

OWASP Top 10 groups common web risks so builders prioritize. In this course you use it as a walk through YOUR four lanes: broken access control (every object re-checked), cryptographic hygiene (TLS and secrets — Topic 8 / Module 20 later), injection (SQL and script — named only; Topic 10 and Module 15 hold the depth), insecure design (missing threat model, missing rate limits from Module 10), misconfiguration (defaults, verbose errors — Module 13 overlap), outdated components, authentication failures, integrity of builds, logging gaps, SSRF (server fetches a URL the client chose — Topic 10, no payload here). You do not memorize a dump table for a cert. You do not treat the list as permission to prove each item against a random host.

Injection and XSS are the two names beginners want as copy-paste. This lesson will not give you those strings. Topic 10 already teaches SQL theory, types, prevention, XSS types, encoding, and labs on surfaces Cyberlium owns. Module 15 will show why concatenating SQL turns the query into attacker-controlled text — mechanism plus parameterized queries as the fix, still no live SQLi against others. Your job in Module 14 is methodology: name the lane, name the OWASP bucket, write the fix pattern (Lesson 3), stay in scope (Lesson 2).

An app-surface note is boring on purpose. Date (UTC). Four lanes in your own words. OWASP used as a checklist for a labeled app YOU own or a hypothetical you would own — not a classmate hostname. Pointer: deep SQLi/XSS live in Topic 10; this file has no exploit strings. Ethics: no random sites, no sqlmap, no “quick XSS on the café Wi-Fi portal.” Legal line: original Cyberlium teaching mapped to the CEH v13 web-applications domain — not official EC-Council training, not a cert, not exam dumps. Path: $HOME/cyberlium-lab/app-surface-notes.txt, chmod 600. Empty files fail. Files that list target URLs you do not own fail even if you “only planned.” World-readable 777 fails.

A useful feeling: the lesson is “too small” because you did not pop an alert or dump a table. That feeling is how people graduate into unauthorized app testing. The skill is stopping at names. Lesson 4 will let you list routes on an app you own or a loopback demo. Until then, a filled definition file is a complete Lesson 1. Do not add a production hostname because definitions felt later.

On a computer you own, create cyberlium-lab if needed. Fill the template in your own words. Do not add payload samples. Do not add a host you do not own. chmod 600. The block below writes the file and refuses to become an attack kit.

cat >> "$NOTES" << 'EOF'
owasp_use: checklist on MY app / localhost demo
owasp_not: hunting menu, exam dump, random-site payloads
EOF

You now treat the application as four named lanes — input, authentication, session, access control — and you treat OWASP as a builder checklist, not a license to hunt. Deep SQLi and XSS stay in Topic 10; this file has no exploit strings. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 web-applications domain — not official EC-Council training, not a cert, not exam dumps. Next — Authorized Testing vs Random Sites — bug-bounty rules you actually read, DVWA only if YOU run it locally, default YOUR app or a local demo.