Security looks like a thousand unrelated bugs. SQL injection, broken access control, use after free, server-side request forgery, a subdomain takeover, an integer overflow in a codec. A beginner tries to memorize them one at a time and drowns. The list never ends, and every new framework invents ten more names for the same thing.

They are not a thousand things. They are one thing, seen from seven angles.

Every vulnerability is the same move. An attacker crossed a trust boundary that was supposed to hold. The system assumed something would stay on one side of a line, and it did not. Classify by which line broke, and the thousand names collapse into seven boundaries. The first half of this piece is the model. The second half is the complete checklist that falls out of it, so you can run the whole surface without skipping anything.

The one sentence

A vulnerability is a crossed trust boundary.

That is the whole field in six words. Everything else is which boundary, at which layer, in how many steps. The names on the thousand-item list describe the technique. The boundary describes the reason the technique works. Technique changes every year. The boundaries have not changed in decades, because they come from how systems are built, not from what tool is in fashion.

The seven boundaries

1. Identity. The system has to answer "who are you," and it answers wrong. An attacker forges or bypasses the proof. The question: can the proof of identity be forged or skipped?

2. Authorization. Identity is real this time, but the user reaches past what they are allowed to touch. The question: with a valid account, can I reach another account's data or another tenant's world?

3. Data versus code. Input that was supposed to be data gets executed as code. The injection family. The question: can my input stop being a value and start being an instruction?

4. The confused deputy. A trusted intermediary is tricked into acting for the attacker. The essence is not injecting code, it is borrowing a hand the system already trusts. The question: can I make a trusted party act on my behalf?

5. Business logic. Every technical check passes and the rules still have a gap. The question: does the business rule have a case nobody wrote down?

6. Configuration. Someone left a door open. A dangling DNS record, a key in a public repo, an internal dashboard exposed. The question: is there a door left open that was supposed to be shut?

7. Memory. The program writes outside the bounds or the lifetime it intended, and the machine keeps running on corrupted state. The question: can I write outside the lines the program drew?

Whatever bug you are staring at, it is a crossing of one of these, or a chain of several.

Three distinctions people get wrong

Authentication is not authorization. Authentication is who you are. Authorization is what you can do. Most of the money lives in authorization, especially object-level access control and multi-tenant isolation, because crossing from one user or one company to another is direct harm.

The confused deputy is its own class. Do not fold server-side request forgery into injection. Injection makes the target run your code. A confused deputy makes a trusted party run your errand with its own authority. On the web, the server's network position is worth far more than its CPU.

One bug can span two boundaries. Cross-site scripting is both injection and confused deputy, which is why it is so often the first link in a chain.

The layer decides the weapon

The boundary tells you the kind of bug. The stack layer tells you which boundaries are even on the table.

Memory corruption, boundary seven, only exists where code touches raw memory. That is the C, C++ and assembly world of firmware and native applications. In the managed world of Python, JavaScript, Go and Java, boundary seven is absent. The runtime checks the bounds and manages the lifetimes, so those systems break on boundaries one through six instead.

So there are two battlefields and the weapons do not transfer. Hunting for an overflow in a Go backend is hunting for an animal that does not live there. The rest of this checklist is the web and SaaS battlefield: boundaries one through six, in the order you should sweep them. For boundary seven, native memory corruption, see the companion piece.

The stack layer decides which boundaries are on the table. The binary and memory layer carries boundary seven, memory corruption. The server application carries boundaries one through five. The client carries cross-site scripting and request forgery. The infrastructure layer carries configuration. Two battlefields, different weapons.

The checklist

Run it top to bottom on an authorized target. A fixed order is the point. It is how you stop skipping the boring category where the finding actually was.

0. Reconnaissance and attack-surface mapping

Map before you touch anything.

  • Enumerate subdomains from multiple sources, passive first, then merge and dedupe.
  • Probe what is alive. Capture status, title, tech stack, server, CDN.
  • Port and service scan the live hosts. Look for exposed dev services: Grafana, Kibana, Jenkins, Airflow, Consul, Vault.
  • Pull every JavaScript file and read it. Source maps, API endpoints, internal URLs, hardcoded keys. Grep for api_key, secret, token, internal.
  • Discover endpoints from crawl plus archived URLs, then directory brute force with a sane wordlist.
  • Check for exposed secrets and metadata: .git/, .env, /actuator, /swagger, /openapi.json, /graphql, .map files.
  • Fingerprint the stack: framework, template engine, cloud, CDN, WAF.
  • Register the accounts you will need, more than one, so you can cross-check access between them later.

1. Authentication

The boundary: can identity be forged or skipped?

  • Weak password policy, password spraying, credential stuffing. Is there rate limiting?
  • User enumeration across three surfaces: registration, login, and password reset. Watch for differences in timing, wording, and status code.
  • Password reset: is the token predictable, non-expiring, or reusable? Can a Host header poison the reset link's domain? Can a parameter inject into the reset email?
  • JSON web tokens: alg=none, weak HMAC secrets, key-id injection, algorithm confusion where an RS token is verified as HS, and headers that point key material at an attacker.
  • OAuth and SSO: redirect-uri validation (prefix, suffix, subdomain, path traversal, @ confusion), a missing state which is CSRF, downgrade to a weaker challenge, leaked codes, and account-linking confusion.
  • Session handling: does it survive logout? Does an old session survive a password change? Is the token predictable? Session fixation? Are cookies missing HttpOnly, Secure, or SameSite?
  • Two-factor: bypass by jumping straight to the authenticated page, brute force of the one-time code, backup-code logic, and response tampering that flips a success flag.

2. Authorization

The highest-value boundary. Test it with two accounts side by side.

  • Object-level access control. Swap an object id, sequential or UUID or encoded, and reach another user's resource. Confirm with a second account.
  • Function-level access control. Call an admin endpoint from a normal user. Try privileged verbs the UI never shows.
  • Multi-tenant isolation. Swap a tenant or company id wherever it appears: URL, header, body, or a token claim. Look across the tenant line.
  • Mass assignment. Post extra fields the form never sent: a role, a verified flag, a company id, a price.
  • Parameter pollution. Duplicate a parameter, mix array and object types, and see which one the server trusts.

3. Injection

The boundary: does input become code?

  • SQL and NoSQL injection on every parameter, including ones an ORM looks like it should protect. Classic quotes, boolean, and time-based blind.
  • Command injection in anything that touches the shell: filenames, export jobs, webhook targets.
  • Server-side template injection. The simple arithmetic probes tell you the engine, then you test whether the sandbox holds. Watch for data that gets evaluated as a template a second time.
  • XML external entities anywhere XML enters: SOAP, SAML, office documents, SVG, feeds. Out-of-band exfiltration when the response is blind.
  • CRLF and header injection into headers, redirects, and email.
  • Email header injection and sender spoofing through template sender fields.
  • The long tail: LDAP, XPath, server-side includes.

4. Client side

The boundary runs through the victim's browser.

  • Cross-site scripting: reflected on every echoed parameter, stored in comments, names, profiles, and event attributes, and DOM-based through sinks like innerHTML and location. On a modern framework, look for the explicit escape hatch and check any sanitizer's version against known bypasses.
  • Cross-site request forgery on state-changing endpoints with no token, an unchecked token, or a loose SameSite. Test the JSON content-type bypass.
  • Cross-origin resource sharing that reflects the Origin with credentials enabled. Try evil, null, suffix, and subdomain origins.
  • postMessage handlers with no origin check, and cross-site WebSocket hijacking for the same reason.
  • Prototype pollution through query and JSON bodies, then look for a gadget to turn it into something.
  • Clickjacking, reverse tabnabbing, and DOM clobbering.
  • Open redirect on the usual next, redirect, url, and return parameters. On its own it is minor. It is the first link that steals an OAuth token.

5. Server side and infrastructure

  • Server-side request forgery in any feature where the server fetches a user-supplied URL: feed imports, image imports, webhooks, PDF generation, avatars, link previews. Prove the callback, reach the internal network and the cloud metadata address, and expect to bypass filters with redirects, DNS rebinding, encoded addresses, and alternate schemes.
  • Insecure deserialization across the common formats. Magic bytes plus a known gadget.
  • File upload: type-check bypass by magic byte or double extension, SVG that carries script, archive path traversal, and the path where an upload becomes code execution.
  • Path traversal and local file inclusion.
  • Race conditions: hit a coupon, a balance, an invite, or a purchase limit with concurrent requests. Single-packet techniques expose the smallest windows.
  • Business logic: price and quantity tampering including negatives, workflow steps skipped, predictable or unlimited promo codes, quota and rate bypass, double refunds.
  • HTTP request smuggling from front-end and back-end parsing disagreements, which leads to cache poisoning and credential hijack.
  • Web cache poisoning and deception through unkeyed headers and path confusion.
  • Subdomain takeover from a dangling CNAME pointing at an unclaimed third-party service.
  • Dependency confusion: an internal package name registered on a public registry.

6. API specifics

  • Excessive data exposure. The API returns more fields than the UI shows: internal flags, other users' data, PII.
  • GraphQL. If introspection is on, dump the schema. If it is off, brute-force field suggestions. Watch for batching that amplifies denial of service or bypasses rate limits, and check authorization on every mutation.
  • Old API versions that still carry a bug a newer version fixed.
  • Missing rate limits on anything enumerable.
  • Content-type confusion that switches between JSON, form, and XML to slip past a check.

7. Information disclosure

  • Verbose errors, stack traces, and debug mode left on.
  • Directory listing, backup files, and exposed source control.
  • Exposed API documentation and GraphQL playgrounds.
  • Metadata, internal hostnames and addresses, and credentials sitting in client-side JavaScript.

8. The modern surface

  • Model-context-protocol servers: open dynamic client registration, authorization metadata, and access-control or injection bugs in the tools behind authentication.
  • Prompt injection anywhere an AI feature reads untrusted input, leading to privilege escalation, data disclosure, or tool abuse.
  • SAML signature stripping and wrapping.
  • Passkey and device-code logic.

9. Chaining

The craft. Single findings are usually modest. The report that pays is the chain.

Chaining small findings into one compromise. Cross-site scripting steals a session and becomes account takeover. Request forgery reaches cloud metadata, yields a credential, and opens the bucket. An open redirect steals an OAuth code and becomes account takeover.

  • Script injection steals a session and becomes account takeover.
  • Request forgery reaches cloud metadata, yields a credential, and opens the storage bucket.
  • An open redirect captures an OAuth code and becomes account takeover.
  • Cache poisoning turns a local script injection into a site-wide one.
  • Object-level access plus mass assignment becomes privilege escalation.
  • Subdomain takeover inside the cookie scope steals the session.

Never discard a low-severity finding. Ask the other question: is this a link in a chain I have not finished building?

Tools, by phase

  • Recon: subfinder, amass, httpx, katana, gau, waybackurls, nuclei, ffuf.
  • Proxy and replay: Burp Suite with Turbo Intruder for races and smuggling, or Caido.
  • Out-of-band: a request-catcher that can return custom responses, plus an interaction server.
  • Specific: jwt tooling, sqlmap, a DOM XSS scanner, a CORS checker, a takeover checker, a GraphQL auditor, a parameter miner for cache and smuggling.

The map is the asset

Tools in this field have a shelf life measured in months. The seven boundaries do not, because they come from the shape of how we build systems. A system has to know who you are, decide what you can do, separate data from code, trust some intermediaries, encode its own rules, stay configured, and manage its own memory. Those seven obligations are the seven boundaries, and every one can fail.

Memorize bugs and you are always behind the next release. Hold the seven and you can place any new vulnerability the day it is named, because it is never actually new. It is one of these seven, at one of two layers, in one or more steps.

The seventh boundary, memory, is the strangest of the group. It exists in only one world, it is the hardest to cross, and it pays the most when you do. It gets its own first-principles treatment, down to the stack frame and the register, in the companion piece.