How web apps actually break

7 min read

Almost every web vulnerability is one of two failures: the app trusts input it should not, or the app forgets to check who is asking. Injection, XSS and deserialisation are the first. Broken access control and IDOR are the second. Everything else is a variation.

The attacker's tool is not a scanner — it is an intercepting proxy that lets you see and edit every request the browser sends. The browser is just the app's opinion of what you are allowed to do; the proxy is where you disagree with it. A field marked readonly, a price in a hidden input, a role in a cookie, an id in a URL — all of it is a suggestion until the server re-validates it, and the whole game is finding the places the server forgot to.

The map

• Access control — can you reach or change something that is not yours? IDOR (/account?id=1001 → try 1000), forced browsing to hidden paths, privilege fields the client sets.
• Injection — SQL, OS command, template, LDAP. Your input crosses out of data and into code because it was concatenated, not parameterised.
• Client-side — XSS (your script runs in another user's page), CSRF, clickjacking. The server trusted content it should have treated as hostile.
• Information disclosure — verbose errors, robots.txt, backup files, debug endpoints, comments. The app tells you how to break it.
• Broken authentication — guessable tokens, logic you can skip, secrets on the client. If security state lives in something the client can edit, it is not security.

The labs below are one from each family. Read the artifact like a proxy would show it to you.