We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

How Attackers Think

When attackers target a web application, they're usually after:

  • Money: Theft through payments, refunds, or extortion
  • Data: Email addresses, names, and credentials to abuse or sell
  • Access: Control of powerful accounts or admin panels
  • Disruption: Making a service unreliable for notoriety or competitive advantage

Attackers don't have to use your front-end interface or obey its client-side restrictions. They can interact with your back end directly. Just because your website's UI hides the "Delete All Users" button for non-admins doesn't mean an attacker can't send a direct DELETE request to your /users endpoint using curl or Postman.

Trust Boundaries

A trust boundary separates parts of a system with different levels of trust. For example, you control your server code, but you don't control the code or data in a user's browser.

Treat data crossing from the browser to your server as attacker-controlled. The server needs to validate that data and authorize the requested operation instead of blindly trusting client-side checks.

Threat modeling means examining a system from an attacker's perspective. We can't predict every possible attack, but we can use STRIDE to prompt us to look for six common classes of threats:

  • Spoofing: Pretending to be another user
  • Tampering: Changing data in transit or at rest without authorization
  • Repudiation: Denying an action because the system lacks reliable records
  • Information disclosure: Accessing data that shouldn't be visible
  • Denial of service: Making the system slow or unavailable
  • Elevation of privilege: Gaining permissions you shouldn't have

So, at each trust boundary, ask:

If someone were trying to break this, which failures could occur, and what evidence would reveal them?