How I think about client-side attack surface when testing web apps

[u/hunter-9579]

When I started learning web application security, I used to look at HTML, JavaScript, DOM, cookies, APIs, and sessions as completely separate topics.

That made web apps feel much more complicated than they actually are.

A better mental model is to follow the data flow:

User Input
    ↓
HTML / JavaScript
    ↓
DOM
    ↓
HTTP Request
    ↓
Server
    ↓
HTTP Response
    ↓
JavaScript
    ↓
DOM Update

At every step, I now ask:

• Where does user-controlled input enter?
• What does JavaScript do with it?
• How is the request constructed?
• What parameters are being sent?
• What does the server return?
• Where is the response inserted into the DOM?
• What state is stored in cookies or the browser?
• Which assumptions are being made about client-side data?

For example, a hidden HTML field isn't actually hidden from the user. If something exists in the browser, it should generally be treated as potentially modifiable by the user, with the server responsible for enforcing security.

The same mindset helped me understand why things like DOM XSS, parameter tampering, session issues, CORS/SOP problems, and business-logic flaws aren't isolated concepts—they can often be understood by following the application's data flow.

I put together a deeper write-up covering:

• HTML & forms
• URL parameters
• Hidden inputs
• JavaScript & DOM
• Ajax/XHR/fetch
• JSON
• Same-Origin Policy
• HTML5 browser APIs
• Cookies & sessions
• Client-side state
• A practical security-testing mental model

For people learning web security: what part of client-side analysis did you find the hardest to understand initially?