Web Application Security

Almost every web vulnerability reduces to one sentence: data got interpreted as instructions, or untrusted input got trusted.

• URL parameter → database query = SQL injection
• Comment field → rendered as HTML/JS = XSS
• User-supplied URL fetched by the server = SSRF
• Object ID changed from /invoice/1042 to /invoice/1043 = IDOR

The defender’s fix is always some flavor of: validate, escape, and never let user data become code. The attacker’s skill is noticing where that rule was forgotten. Practice habit: for any input field ask “what does the server do with this?” — then try to answer it wrong on purpose.

If a query is built by string concatenation:

query = "SELECT * FROM users WHERE name = '" + input + "'";

…then typing ' OR '1'='1 makes it return everyone. Classic tests: ', ", ' AND 1=1-- -. A union attack can read other tables: ' UNION SELECT username, password FROM users-- -. Blind SQLi leaks data one true/false question at a time (or via time delays).

Command injection is the same idea at the OS level: an app runs ping with your input, so ; cat /etc/passwd gets appended. Separators to try: ; | && ` $().

Defense: prepared statements (SQL) and never passing user input to shells. Detection in logs: quotes and SQL keywords hitting strange places.

Cross-Site Scripting injects JavaScript that runs in victims’ browsers:

• Reflected: payload arrives via URL (?q=<script>...</script>) and renders immediately — needs the victim to click your crafted link.
• Stored: payload saved (profile bio, comment) and fires for every visitor — the dangerous one.
• DOM-based: client-side JS reads attacker-controlled data into dangerous sinks like innerHTML.

Impact: session theft (document.cookie), keylogging, fake login overlays, silent requests as the victim.

Defenses: contextual output encoding, Content-Security-Policy, HttpOnly cookies (blocks JS reads), frameworks’ auto-escaping. Quick test string everywhere: alert-domain<svg onload=alert(1)> — then prove impact beyond alert popups in real reports.

IDOR: the app fetches /api/orders/1042 based on a guessable ID and forgets to check it’s your order. Test: create two accounts, swap IDs, see if you read each other’s data. Boring, common, pays well.

Other heavy hitters:

• SSRF — server fetches a URL you control: url=http://169.254.169.254/ hits cloud metadata creds.
• File upload flaws — uploading shell.php.jpg or polyglots when type checks are sloppy.
• Security misconfig — default creds, directory listing, verbose stack traces, exposed .git.
• Broken auth — no rate limiting, weak reset flows, JWTs that don’t verify signatures.

Don’t memorize the list — internalize the pattern: the server forgot who’s asking / what this input is. Then go raid the site’s own web payloads vault for technique references.