What you’ll be able to do
- Name ShopCart’s assets, entry points, and at least three trust boundaries on an eight-node sketch.
- Write one abuse case for a spoofed payment webhook, an over-scoped worker, and an order-ID mix-up.
- Explain why a fresh check at the boundary is required even when the caller is inside a private network.
- Choose one control that still holds if the network access list is wrong.
HTTPS to the load balancer is not the map
Facilities asks Maya whether Riverstone can run a tiny employee-merch checkout. She does not start with TrackPort. She draws ShopCart, a synthetic API that exists only for this lesson. It is not a real merchant, and it is not a claim about any vendor’s checkout. The sketch has eight nodes: a browser, a public API, a worker that emails receipts, Postgres for orders, an object store for invoice PDFs, an admin panel, a payment provider, and the webhook that says an order was paid.
A padlock on the way to the load balancer means the bytes were protected in transit and a certificate name was checked. Foundations already taught that for TrackPort. ShopCart’s question is different: after the request arrives, who is trusted to mean “this order is paid,” “this worker may read every invoice,” or “this admin may change a price”? NIST SP 800-207 (final, August 2020) refuses implicit trust from network location or asset ownership. A private address is not a pass.
Each boundary gets its own check
Maya marks four places where the assumption changes. The browser crosses into the public API: the API authenticates the employee and authorizes that employee’s order. The payment provider crosses into the webhook: the API verifies a signature on the paid event before it writes “paid.” The API and the receipt worker cross into Postgres and the object store: each identity can touch only the rows and objects its job needs. The admin panel crosses into the API on a separate login, not on the customer session.
Least privilege from F5 is the same sentence here, checked where the data lives. If the network access list is wrong and the webhook is reachable from anywhere, signature verification still has to reject a forged paid event. If the worker’s cloud role can delete every invoice, a firewall between subnets does not fix that role. OWASP Top 10:2025 lists Insecure Design (A06:2025) as an awareness category and notes industry attention on threat modeling. That category names a gap. It does not mandate a method, and it is not a finished test of ShopCart.
- Browser to API: authenticate the caller, then authorize the order.
- Payment webhook: verify the signature. Do not trust the source address.
- Worker and API to data stores: scope the service account to this job.
- Admin panel: a separate identity, not a hidden customer route.
| Node | What it holds | Abuse case if the check is missing |
|---|---|---|
| Browser | Cart form | Client-side totals treated as the price |
| Public API | Orders | Order 18 returned to the caller of order 19 |
| Receipt worker | Email job | Worker role reads every invoice PDF |
| Postgres | Orders and accounts | Query trusts the caller’s order id |
| Invoice object store | PDF invoices | Broad role lists the whole bucket |
| Admin panel | Refunds and prices | Customer session opens admin routes |
| Payment provider | Card charge | Outside ShopCart; not a Riverstone control |
| Payment webhook | Paid events | Forged event marks an unpaid order paid |
Worked abuse cases, then one control that stands alone
Maya writes three abuse cases in plain language. Spoofed webhook: anyone who can POST a body that looks like “order 18 paid” changes the order without paying. Over-scoped worker: the receipt job’s role can list and delete every object, so a bug or a stolen token is an availability and confidentiality loss for invoices. Insecure direct object reference: changing 18 to 19 in the URL returns another employee’s merch order, address included. Each case names the boundary that failed.
The control she keeps even if the network rule is wrong is signature verification on the webhook, plus an authorization check on the order id inside the API. Those checks do not depend on the previous hop. F5’s warehouse rooms and F5b’s TrackPort client boundary are the same habit on different drawings. ShopCart does not replace them.
CHECK YOUR JUDGMENT
A teammate says ShopCart’s payment webhook needs no signature check: TLS ends at the load balancer, and the webhook path is allowed only from the payment provider’s addresses. What should Maya record?
NEXT FIELD LESSON