Food Delivery Startup - Attack Tree Focused Example

This case study shows a lighter-weight threat modeling approach centered on attack trees. This example demonstrates that not every system needs the full PASTA methodology.

Attack trees shine when you have clear attacker goals and want to understand the multiple paths to achieving them. They are visual, intuitive, and excellent for communicating with non-security stakeholders. For a Series A startup with a small security budget, attack trees provide the most insight per hour invested.

The System: FlashFork Food Delivery

FlashFork is a food delivery startup operating in three mid-sized cities. Think DoorDash’s younger, scrappier cousin.

The company handles payment card data (via Stripe—they don’t store it themselves), personal information, location data, and restaurant financial information. A breach would hurt, but it wouldn’t make national news. The goal is proportionate security, not paranoid security.

Quick System Overview

Rather than exhaustive data flow diagrams, here’s what matters for threat modeling:

Three User Types, Three Apps

Customers use the iOS/Android app to browse restaurants, order food, and pay. They authenticate via email/password or social login (Google, Apple). The app tracks their location to show nearby restaurants and estimate delivery times.

Drivers use a separate app to accept deliveries, navigate to pickups and dropoffs, and mark orders complete. They’re gig workers, not employees, which creates interesting trust dynamics. The driver app has access to customer names, addresses, and phone numbers for each delivery.

Restaurants use a web dashboard to manage menus, accept/reject orders, and view earnings. Some high-volume restaurants also use a tablet app that makes a noise when new orders arrive.

Backend Architecture

A fairly standard setup: React Native mobile apps and React web apps talking to a Node.js API running in ECS containers. PostgreSQL on RDS stores everything. Redis handles sessions and caching. Stripe handles payments. Twilio handles SMS notifications. Google Maps API powers location features.

What’s Worth Stealing

Customer PII (names, addresses, phone numbers, order history), driver PII (includes SSN for tax purposes, bank account for payouts), restaurant financial data (revenue, payout information), and the ability to place fraudulent orders or steal delivery payouts.

Threat Identification: STRIDE Checklist

Before building attack trees, a quick STRIDE pass identifies the threat categories we care about. This isn’t exhaustive analysis—it’s enough to know where to focus.

The STRIDE pass confirms our intuitions: fraud and data theft are the primary concerns. Availability matters during peak hours but isn’t existential. Now let’s build attack trees for the goals that matter most.

Attack Tree 1: Steal Customer Database

Goal: Exfiltrate the customer table (~150,000 records with names, emails, addresses, phone numbers, order history)

This is the obvious target. Customer data has resale value on dark markets, enables phishing campaigns, and would trigger breach notification obligations.

Steal Customer Database
├── 1. Exploit Application Vulnerability
│   ├── 1.1 SQL Injection in search/filter endpoints
│   │   └── Likelihood: Medium (modern ORMs help, but custom queries exist)
│   ├── 1.2 IDOR in customer profile API
│   │   └── Likelihood: Medium-High (common in fast-moving startups)
│   └── 1.3 GraphQL introspection + excessive data exposure
│       └── Likelihood: Medium (if GraphQL is used)
│
├── 2. Compromise Application Infrastructure
│   ├── 2.1 AWS credential theft
│   │   ├── 2.1.1 Credentials in git repo
│   │   ├── 2.1.2 Phish developer with AWS access
│   │   └── 2.1.3 Compromise CI/CD pipeline
│   ├── 2.2 Database direct access
│   │   ├── 2.2.1 RDS publicly accessible (misconfiguration)
│   │   └── 2.2.2 Weak database password + credential stuffing
│   └── 2.3 Container escape
│       └── Likelihood: Low (requires sophisticated attacker)
│
├── 3. Abuse Legitimate Access
│   ├── 3.1 Malicious insider with database access
│   │   └── Likelihood: Low-Medium (small team, but access controls likely weak)
│   ├── 3.2 Compromised support account with customer lookup
│   │   └── Likelihood: Medium (support tools often overpowered)
│   └── 3.3 Third-party vendor breach (analytics, marketing tools)
│       └── Likelihood: Low-Medium (depends on what data is shared)
│
└── 4. Backup/Export Exploitation
    ├── 4.1 S3 bucket with database backups publicly accessible
    │   └── Likelihood: Medium (common misconfiguration)
    └── 4.2 Intercept database export intended for analytics
        └── Likelihood: Low

Highest-Risk Paths

Looking at this tree, three paths stand out as most likely to succeed:

Path 1.2 (IDOR) is probably the easiest win for an attacker. Fast-moving startups often have API endpoints like /api/customers/{id} where the authorization check is missing or broken. An attacker iterates through customer IDs and downloads everything. This requires only a valid customer account and basic scripting skills.

Path 2.1.1 (Credentials in Git) is embarrassingly common. Someone commits an .env file or hardcodes a connection string during debugging and forgets to remove it. Tools like truffleHog and GitLeaks find these automatically. If the repo is public or gets leaked, game over.

Path 4.1 (Public S3 Bucket) has caused countless breaches. The database backup bucket is configured incorrectly, someone finds it via S3 enumeration, and suddenly your entire customer database is on a forum somewhere.

Mitigations by Path

The good news: the highest-risk paths are also the cheapest to fix. IDOR testing, secret scanning, and S3 configuration are table-stakes security that a part-time security engineer can implement in a sprint.

Attack Tree 2: Commit Order Fraud

Goal: Get free food or money through fraudulent orders

Fraud is a constant problem for delivery platforms. Unlike data theft, fraud provides immediate tangible value to attackers and attracts a different (often less sophisticated but more numerous) adversary population.

Commit Order Fraud
├── 1. Payment Fraud
│   ├── 1.1 Use stolen credit cards
│   │   ├── 1.1.1 Carding with purchased card dumps
│   │   ├── 1.1.2 Social engineering customers for card info
│   │   └── 1.1.3 Intercept card data (unlikely—Stripe handles this)
│   ├── 1.2 Chargeback fraud
│   │   └── Place order, receive food, dispute charge with bank
│   └── 1.3 Exploit promo codes
│       ├── 1.3.1 Generate valid promo codes (if predictable pattern)
│       ├── 1.3.2 Abuse referral program with fake accounts
│       └── 1.3.3 Stack promos in unintended ways
│
├── 2. Delivery Fraud (Driver Collusion)
│   ├── 2.1 Driver marks order delivered, keeps food
│   │   └── Customer disputes, platform eats the loss
│   ├── 2.2 Driver and customer collude
│   │   └── "Deliver" to self, split free food
│   └── 2.3 Fake driver accounts for payout fraud
│       └── Create fake deliveries, collect driver pay
│
├── 3. Account Fraud
│   ├── 3.1 Account takeover via credential stuffing
│   │   └── Order to new address using victim's saved payment
│   ├── 3.2 Account takeover via support social engineering
│   │   └── "I lost my phone, can you reset my account?"
│   └── 3.3 Synthetic identity fraud
│       └── Create accounts with fake identities for repeated fraud
│
└── 4. Price/Order Manipulation
    ├── 4.1 Modify order total after restaurant confirms
    │   └── Likelihood: Low if proper order immutability
    ├── 4.2 Exploit rounding errors
    │   └── Rare but devastating when found
    └── 4.3 Race condition in promo application
        └── Apply same promo to multiple orders simultaneously

Highest-Risk Paths

Path 1.2 (Chargeback fraud) is essentially unsolvable through technical controls. Customers order food, eat it, then call their bank claiming they never authorized the charge. The bank sides with the cardholder. FlashFork absorbs the loss. This is a business operations problem more than a security problem, but threat modeling should acknowledge it.

Path 1.3.2 (Referral abuse) is extremely common. Fraudsters create dozens of fake accounts, refer themselves, and collect referral credits. At scale, this can cost real money. Detection requires fraud analytics, not just application security.

Path 2.1 (Driver keeps food) is hard to prevent at the technical level. GPS confirms the driver was at the address, but it can’t confirm they handed food to the customer. Photo-on-delivery and customer confirmation help but don’t eliminate the problem.

Path 3.1 (Credential stuffing) is the most technical path and the most preventable. Attackers use username/password pairs from other breaches and try them against FlashFork. When someone reuses passwords (most people do), the attacker gets in.

Mitigations by Path

Fraud prevention is an ongoing arms race. Unlike patching an IDOR vulnerability, fraud defenses need continuous tuning as attackers adapt.

Attack Tree 3: Compromise Driver Accounts

Goal: Take over driver accounts to steal earnings or access customer data

Driver accounts are valuable targets because they contain bank account information (for payouts) and have access to customer PII for every delivery they make.

Compromise Driver Accounts
├── 1. Credential-Based Attacks
│   ├── 1.1 Credential stuffing (email/password reuse)
│   │   └── Likelihood: High (drivers less likely to use unique passwords)
│   ├── 1.2 Phishing for driver credentials
│   │   ├── 1.2.1 Fake "update your payment info" emails
│   │   └── 1.2.2 Fake driver app (typosquatting in app stores)
│   └── 1.3 Brute force attack
│       └── Likelihood: Low if rate limiting exists
│
├── 2. Session/Token Theft
│   ├── 2.1 Session hijacking via insecure WiFi
│   │   └── Drivers often use public WiFi while waiting
│   ├── 2.2 Token theft from device malware
│   │   └── Drivers use personal phones, may have malware
│   └── 2.3 Token theft from app vulnerability
│       └── Insecure token storage, logging tokens, etc.
│
├── 3. Support Channel Exploitation
│   ├── 3.1 Social engineer support to change payout account
│   │   └── "I have a new bank account, please update it"
│   ├── 3.2 Social engineer support to reset password
│   │   └── Bypass account recovery with sob story
│   └── 3.3 Insider threat (support agent steals accounts)
│       └── Likelihood: Low but impact is high
│
└── 4. Device/Physical Access
    ├── 4.1 Stolen/lost phone with driver app logged in
    │   └── Likelihood: Medium (gig workers, phone-dependent)
    ├── 4.2 Shoulder surfing PIN/password
    │   └── Drivers enter credentials in public constantly
    └── 4.3 Malicious charger/accessory
        └── Likelihood: Very Low

Highest-Risk Paths

Path 1.1 (Credential stuffing) is the clearest threat. Drivers aren’t security professionals. Many use the same password everywhere. Breaches at other services provide attackers with working credentials.

Path 3.1 (Social engineering support) is concerning because the payout is immediate. An attacker convinces support to change the bank account, then cashes out the driver’s pending earnings. By the time the real driver notices, the money is gone.

Path 4.1 (Stolen phone) is underappreciated. Drivers are out in public all day with phones that are permanently logged into the driver app. A stolen phone means instant access to the driver account, all pending deliveries, and customer information for recent orders.

Mitigations by Path

The payout change attack is particularly worth addressing because it’s cheap to mitigate (require email confirmation and a 48-hour cooling-off period) and prevents immediate financial loss.

Attack Tree 4: Disrupt Operations During Peak Hours

Goal: Make the platform unavailable during Friday/Saturday dinner rush (highest revenue period)

For a food delivery startup, downtime during peak hours is disproportionately painful. Losing two hours on a Saturday night might represent 15% of weekly orders.

Disrupt Peak Hour Operations
├── 1. Application-Layer Attacks
│   ├── 1.1 DDoS against API endpoints
│   │   └── Likelihood: Low-Medium (requires resources or botnet)
│   ├── 1.2 Expensive query exploitation
│   │   ├── 1.2.1 Search with wildcards causing full table scans
│   │   └── 1.2.2 GraphQL nested queries (if applicable)
│   └── 1.3 Order flood (create millions of pending orders)
│       └── Exhaust restaurant/driver capacity with fake orders
│
├── 2. Infrastructure Attacks
│   ├── 2.1 AWS account compromise → terminate resources
│   │   └── Likelihood: Low but catastrophic
│   ├── 2.2 Database corruption/deletion
│   │   └── Via SQL injection or admin credential theft
│   └── 2.3 DNS hijacking
│       └── Redirect app traffic to attacker-controlled server
│
├── 3. Third-Party Failures
│   ├── 3.1 Stripe outage (payment processing)
│   │   └── Can't complete orders without payment
│   ├── 3.2 Twilio outage (notifications)
│   │   └── Orders placed but drivers not notified
│   └── 3.3 Google Maps outage (routing)
│       └── Drivers can't navigate, delivery times explode
│
├── 4. Supply-Side Disruption
│   ├── 4.1 Coordinate restaurant dashboard denial
│   │   └── Attack restaurant-facing systems specifically
│   ├── 4.2 Driver app disruption
│   │   └── Push malicious update, exploit app vulnerability
│   └── 4.3 Fake "platform is down" campaign
│       └── Social media disinformation during actual peak hours
│
└── 5. Ransom/Extortion
    ├── 5.1 Ransomware on production systems
    │   └── Encrypt databases, demand payment
    └── 5.2 Extortion threat
        └── "Pay us or we DDoS you every Saturday"

Highest-Risk Paths

Path 1.3 (Order flood) is interesting because it doesn’t require technical sophistication. An attacker creates many fake customer accounts and places hundreds of orders. Restaurants start preparing food that will never be picked up. Drivers accept deliveries to addresses that don’t exist. Real customers experience delays because capacity is consumed by fake orders. This is hard to distinguish from legitimate high demand until the pattern becomes clear.

Path 3.x (Third-party failures) aren’t attacks, but they’re threats to availability. If Stripe goes down, FlashFork goes down. There’s no practical mitigation except maybe a backup payment processor, which most startups won’t implement.

Path 5.1 (Ransomware) has become the default attack for financially motivated adversaries. Get into the network, encrypt everything, demand Bitcoin. The path to ransomware is usually through phishing or exposed services, not exotic exploits.

Mitigations by Path

The order flood attack is worth emphasizing because it’s creative and not always considered. It’s not a “hack” in the traditional sense—it’s adversarial use of legitimate functionality. Detection requires understanding what normal order patterns look like and flagging deviations.

Prioritized Threat Summary

Combining insights from all four attack trees, here are the threats that matter most for FlashFork:

Recommended Actions

For a startup with limited security resources, focus on the highest-impact, lowest-effort mitigations first.

This Week (Zero/Low Cost)

Verify S3 buckets have Block Public Access enabled. This takes thirty minutes and prevents one of the most common breach causes.

Add a pre-commit hook for secret detection. Tools like detect-secrets or gitleaks catch credentials before they reach the repository.

Review API endpoints for authorization checks. Spend a day looking for IDOR vulnerabilities, especially in customer and driver data access.

Enable MFA for AWS root accounts and any admin access. Non-negotiable baseline security.

This Month (Moderate Effort)

Implement rate limiting on authentication endpoints. This blocks credential stuffing attacks, which appear in multiple attack trees.

Add cooling-off period and email verification for payout account changes. Prevents the support social engineering attack that leads to immediate financial loss.

Set up automated IDOR testing in CI/CD. Catch these vulnerabilities before they reach production.

Deploy CloudFront + AWS WAF in front of API endpoints. Basic DDoS protection and some application-layer filtering.

This Quarter (Higher Effort)

Implement fraud scoring for orders. Flag high-risk orders for manual review before notifying restaurants.

Build detection for order flood attacks. Establish baseline order patterns and alert on anomalies.

Set up immutable backups with tested restoration procedures. Ransomware protection requires both prevention and recovery capability.

Create incident response playbook. When (not if) something goes wrong, having a plan saves hours of confusion.

What We Didn’t Cover (And Why)

This threat model deliberately skips some things a more comprehensive analysis would include.

Compliance mapping: FlashFork handles payment cards (Stripe) and personal data (customers, drivers). A full analysis would map threats to PCI-DSS and GDPR/CCPA requirements. We skipped this because the Stripe integration handles PCI scope and privacy compliance is more about policy than attack trees.

Physical security: Office security, laptop policies, and similar controls matter but aren’t the interesting part of FlashFork’s threat landscape.

Detailed infrastructure hardening: AWS has hundreds of security configurations. A full review would take weeks. We focused on the high-impact items (S3, IAM, network) rather than comprehensive coverage.

Insider threat deep dive: Insider threats appear in the trees but aren’t exhaustively analyzed. With 45 employees, the insider threat is real but manageable with basic access controls and monitoring.

Third-party risk assessment: We noted dependencies on Stripe, Twilio, and Google Maps but didn’t evaluate their security posture. At FlashFork’s size, you accept that these providers are more secure than you are.

The goal was proportionate security, not exhaustive security. A Series A startup with one part-time security engineer can’t implement everything. Attack trees help identify what matters most so limited resources go where they’ll have the most impact.

When to Revisit This Model

This threat model should be updated when:

• The platform expands to new cities (larger attack surface, more attention from fraudsters)
• New features launch that handle sensitive data differently
• A security incident reveals threats we missed
• The company raises a significant funding round (attracts more sophisticated adversaries)
• Regulations change (new privacy laws, payment requirements)

At minimum, revisit annually. Attack trees are easy to update incrementally—add new paths as you discover them, prune paths you’ve mitigated.

Summary

Attack trees provided a practical framework for understanding FlashFork’s threat landscape without the overhead of full PASTA methodology. Four trees covered the goals that matter most: stealing customer data, committing fraud, compromising driver accounts, and disrupting operations.

The analysis revealed that FlashFork’s highest risks come from common vulnerabilities (IDOR, exposed credentials, S3 misconfiguration) rather than exotic attacks. This is good news—the most dangerous threats are also the cheapest to address. A focused security effort on the critical items could dramatically reduce risk within a single quarter.

For startups and smaller organizations, attack trees offer an excellent balance of rigor and practicality. They’re visual enough to share with non-technical stakeholders, structured enough to ensure coverage, and lightweight enough to actually get done.

Part 3c Complete | Attack Tree Example