Security · 32 min read
Common Attack Patterns
A conceptual map of frequent attack classes (injection, spoofing, abuse of trust) and how each maps to assets, adversaries, and trust boundaries you already named in a threat model.
Why this exists
Threat models name what you protect and who might attack. Teams still need a shared vocabulary for how attacks usually work.
Injection, spoofing, and related patterns are not a complete encyclopedia of crime. They are recurring shapes that cross web apps, networks, and APIs. Naming the shape helps you place controls at the right boundary.
This lesson stays conceptual. It does not teach how to weaponize flaws. It teaches how to recognize the pattern, map it to a model, and choose the kind of defense that fits.
Axioms & primitives
- 01An attack pattern is a reusable story: adversary goal, path across a boundary, and failure of a control or assumption.
- 02Most common patterns abuse trust: the system treats attacker-controlled input or identity as if it were honest.
- 03Injection succeeds when untrusted data is interpreted as instructions.
- 04Spoofing succeeds when the system accepts a false identity or false source claim.
- 05Controls map to patterns: validate and parameterize against injection; authenticate and bind identity against spoofing; authorize against abuse of a real identity.
- 06Listing patterns is not a substitute for a threat model. Patterns are prompts that fill the model.
Learning objectives
After this lesson you should be able to:
- Map injection and spoofing each to an asset, an adversary, and a trust boundary in one short paragraph.
- Explain why "the user is logged in" does not stop many common attack patterns.
- Distinguish network eavesdropping threats that encryption helps from application abuse that encryption does not stop.
- Diagnose a symptom (unexpected admin action, foreign SQL fragment in logs) by naming the likely pattern class and the missing check.
- State one control class for injection and one for spoofing without describing exploit steps.
Progressive depth
Read the layers in order for a full explanation. Or open the layer you need.
Intuition
Start from the threat model vocabulary you already have. An asset is what you care about. An adversary has a goal. A trust boundary is where you should stop believing input or identity without a check.
Common attack patterns are how adversaries often cross those boundaries. Injection: they send data that the system mistakenly runs as code or queries. Spoofing: they convince the system they are someone else, or that a message came from a trusted place. Abuse of a real login: they are authenticated, then act beyond what authorization allows (covered deeply on the authn versus authz page).
Think in stories, not tool lists. "Attacker pastes text into a search box and the database obeys it as SQL" is injection at the app-to-database boundary. "Attacker presents a stolen session cookie" is spoofing or credential theft at the browser-to-server boundary. "Attacker changes order id 99 to 100 while logged in" is authorization failure after authentication succeeded.
Encryption and TLS change which eavesdropping stories work on the wire. They do not erase injection or broken access control. Place controls where the pattern crosses trust.
Formal shape
Map each pattern with four fields: adversary capability, asset targeted, boundary crossed, failed assumption.
Injection family: untrusted input is concatenated into a command, query, template, or OS call. The failed assumption is "strings are only data." Structural defenses keep data out of the instruction channel (parameterized queries, allowlists, safe template auto-escaping, avoiding shell interpolation). Validation narrows what may enter. It does not replace separation.
Spoofing family: the system accepts a false principal or false source. Examples include stolen or forged session tokens, weak password guessing against login, DNS or path tricks that point users at the wrong host, and trusting client-supplied identity headers. Defenses include strong authentication, protected session cookies, server-side session binding, and authenticating the peer (TLS server auth for "am I talking to the name I meant?").
Related web and network classes you will hear named: cross-site scripting (injection into HTML/JS context), cross-site request forgery (browser attaches cookies to a request the user did not mean), denial of service (availability attack on capacity), and man-in-the-middle on cleartext paths. Each still reduces to asset, adversary, boundary, and assumption.
STRIDE-style prompts (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) are brainstorming aids. Prefer mapping hits back to your model over collecting acronyms.
Worked examples
Example A: search box builds SQL with string join. Asset: database rows. Boundary: app to database. Pattern: injection. Control class: parameterized query plus least-privilege DB role. Residual risk: logic bugs and overly broad roles remain.
Example B: session cookie stolen via XSS or malware. Asset: account actions. Boundary: browser to app. Pattern: spoofing of the principal using a bearer token. Controls: HttpOnly Secure cookies, short lifetimes, XSS defense, revoke on logout. TLS helps against cafe sniffing of Secure cookies. It does not help if the cookie is already readable to script.
Example C: phishing site with its own valid HTTPS certificate. Asset: password. Boundary: human trust. Pattern: spoofing the intended party to the user. TLS works correctly for the phishing name. The model must include user intent and name confusion, not only "encryption on."
Example D: authenticated user hits DELETE /users/other-id. Pattern: elevation or horizontal privilege abuse. Authn succeeded. Authz failed. Map to the authentication versus authorization lesson.
Example E: cleartext HTTP login on public Wi-Fi. Pattern: eavesdropping / disclosure on the path. Encryption and HTTPS are the matching control class. Different pattern than injection.
Edge cases
Supply chain and dependency compromise: the adversary may already be inside a library you trust. Your boundary moved when you imported the package. Patterns still apply; the peer is now "code you run."
Confused deputy: a privileged service is authenticated, then tricked into using its power for an attacker. The pattern sits between spoofing and authorization failure.
Availability attacks: flooding a login page is not injection. Rate limits and capacity planning are the control class. Do not answer every threat with a crypto product.
Protocol weirdness: some older protocols embed addresses in payloads and interact badly with NAT or proxies. That is not "hacking magic." It is a trust and parsing boundary problem.
Over-focus on exotic exploits: most product failures still come from missing authz checks, injectable query construction, and session mishandling. Rank by your assets.
Legal and ethical boundary: studying patterns to design defenses is the job of this page. Turning patterns into attack runbooks against systems you do not own is out of scope and out of bounds.
Mental models
Poison in the mail slot
The mailbox (input boundary) accepts letters. If the clerk reads a letter as a command to open the vault, injection happened. The fix is not thicker walls alone. It is refusing to treat mail as instructions.
Borrowed badge
Spoofing is walking in with someone else's badge, or a badge the gate never checked. Authorization still matters after the badge is accepted.
Customs forms, not customs gossip
Structured fields (typed parameters) are forms. Free text glued into a command is gossip the system might obey. Prefer forms.
Weather types, not every storm
Pattern classes are storm types (injection, spoofing, denial). Your threat model still picks which storms matter for your assets.
Common misconceptions
Myth
If we use HTTPS, common web attacks go away.
Reality
TLS protects the channel to a validated name. Injected queries, stolen sessions, and broken authorization still work over HTTPS.
Myth
Attack patterns are only relevant to penetration testers.
Reality
Builders use the same vocabulary to place validation, authentication, and authorization at the right boundaries.
Myth
Input validation alone stops all injection.
Reality
Validation helps. Separating data from instructions (parameterized queries, safe APIs, contextual encoding) is the structural fix.
Myth
Spoofing always means IP address forgery.
Reality
Spoofing is broader: fake identity, forged cookies, misleading Host headers, or phishing that tricks a human into trusting the wrong party.
Exercises
Work these without looking up answers first. Check yourself against the intent notes.
Exercise 01
For a notes app, write one injection threat and one spoofing threat. For each, name the asset, boundary, failed assumption, and one control class (not a vendor product).
Hint: Start from what crosses from browser to server, then from app to database.
What good looks like
Learner uses threat-model fields; injection tied to interpreting input as instructions; spoofing tied to false identity or stolen session; controls are structural (parameterize, HttpOnly session, etc.).
Exercise 02
A team says "we are safe because all traffic is HTTPS." Name two common attack patterns that still apply and why HTTPS does not stop them.
Hint: Ask what an attacker can send inside an already-encrypted session.
What good looks like
Injection and broken access control / stolen session use / CSRF-style abuse; TLS protects channel confidentiality and server name auth, not app logic.
Exercise 03
Logs show a logged-in user accessed another tenant's document by changing an id in the URL. Which pattern class fits best, and is this primarily an authentication failure?
Hint: Did the server know who the caller was? Did it check that caller against the document?
What good looks like
Authorization / IDOR-style abuse after successful authn; not primarily authentication failure.
Sources & further reading
External references. Prefer primary documents and clear explainers.
Go deeper on your own
These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.
- OWASP: AttacksDocs
Catalog of named web attack classes with short definitions. Start here to expand beyond a top-ten list.
- MITRE CAPECDocs
Common attack pattern enumeration and classification. Use it when you need structured attack taxonomies.
Annual ranking of dangerous weakness classes. Read it to connect attack patterns to root defect types.