The OSI Model, But It’s Food Delivery

Every security certification makes you memorise the OSI model at some point — seven layers, a mnemonic like "Please Do Not Throw Sausage Pizza Away," and a diagram you forget the moment the exam is over. It never really sticks, because nobody explains it using something you actually do every day.

So here's the version that (hopefully) sticks: the OSI model, explained through ordering food on a delivery app. Every time you order pizza on a Friday night, your phone quietly runs through all seven layers — and so does every attack that could go wrong along the way.

Here's the trip, top to bottom.

Layer 7 — Application: you open the app

You open the app, browse the menu, and tap "order." This is the layer you actually see and interact with — every app, every website, every login screen lives here.

⚠ What goes wrong: this is where most attacks you actually hear about in the news happen — a fake look-alike delivery app (or a fake login page) tricking you into typing your card details, or a bug in the real app that lets an attacker do something they shouldn't. Phishing, SQL injection, cross-site scripting — all layer 7. It's the layer closest to people, and people are usually the easiest thing to trick.

Layer 6 — Presentation: translating your order

"Extra spicy, no onions, ring the bell twice" has to become something the restaurant's system and the payment gateway can actually process — a standard order ticket, a properly formatted transaction. This layer is the translator: taking what you typed and converting it into a format everyone downstream can understand, including encrypting your payment details along the way.

⚠ What goes wrong: if someone can intercept and tamper with that translation step, they can quietly change what gets sent — this is the same idea behind SSL stripping, where an attacker downgrades what should be an encrypted connection so they can read or alter what's actually being transmitted. In practice, TLS blurs the line between this layer and the ones around it — but conceptually, this is still where "translating into something everyone can trust" happens.

Layer 5 — Session: keeping your order tracked as one thread

From the moment you tap "order" to the moment it's marked delivered, the app keeps it as one continuous session — even if your phone dies and you reopen the app twenty minutes later, it still knows exactly where your order is. That continuity, tying together everything that happens between "start" and "finish," is what a session is.

⚠ What goes wrong: if someone steals your order-tracking ID, they can effectively pretend to be you — checking your order status, or worse, redirecting it. This is exactly what session hijacking is: stealing the token that says "this is an ongoing, authenticated conversation" and using it yourself.

Layer 4 — Transport: making sure nothing's missing

If you ordered a pizza, garlic bread, and a soft drink, someone has to check off all three before the bag gets handed to the rider — not two out of three, all three, in the right bag. This is what the transport layer does for data: breaking it into pieces and guaranteeing (if it's using TCP) that every piece arrives, and arrives complete.

⚠ What goes wrong: imagine someone spamming the restaurant with thousands of fake orders that never get confirmed or picked up — the kitchen grinds to a halt trying to keep up, and real orders can't get through. That's a SYN flood: flooding a server with connection requests that are never completed, tying up its resources until legitimate traffic can't get in.

Layer 3 — Network: mapping the route across the city

Getting from a restaurant in one part of the city to your door in another requires figuring out an actual route — which roads, which turns, which shortcuts. This is what IP addressing and routing do: figure out the path data takes from one network to another, hopping through however many stops it takes to get there.

⚠ What goes wrong: if someone can quietly feed the map bad directions, deliveries — or in networking terms, entire chunks of internet traffic — can get rerouted somewhere they were never meant to go. That's the idea behind IP spoofing and, at internet scale, BGP hijacking, where false routing information sends traffic through a path an attacker controls.

Layer 2 — Data Link: finding your exact door

Once the rider is in your neighborhood, the citywide route stops mattering — now it's about finding your specific building, the right floor, the right door. This last-mile, local-only matching is what the data link layer does, using MAC addresses to identify specific devices on the same local network, the way your street address identifies your specific door.

⚠ What goes wrong: picture someone impersonating the delivery rider at your gate to intercept the handoff. On a network, that's ARP spoofing — tricking devices on the same local network into thinking the attacker's device is the one they meant to talk to, silently inserting themselves into the handoff.

Layer 1 — Physical: the actual road and the actual bike

Strip away every app, every route, every translation — at the bottom, someone is physically riding a bike down a physical road carrying your food. This is the physical layer: actual cables, actual radio waves, actual hardware. No "data" yet, just the raw medium everything else rides on.

⚠ What goes wrong: someone literally intercepting the bike, or in networking terms, physically tapping a cable or setting up a rogue Wi-Fi hotspot to catch traffic before it even becomes structured data. It doesn't take cleverness with protocols — it takes physical access, which is exactly why "who can walk into this building and plug something in" is a real security question.

Why bother remembering any of this

Because it tells you what a given security tool can actually protect against, and what it can't. A firewall filtering by IP and port is working at layers 3–4 — it has no idea what's inside an HTTPS request, so it can't catch a rigged order ticket at layer 7 (like a SQL injection). A VPN protects the route at roughly layer 3, but does nothing if the app itself is compromised at layer 7. A Web Application Firewall works at layer 7 specifically because that's where things like SQL injection and XSS actually live.

That's the real case for defense in depth: a locked server room (layer 1) doesn't stop a phishing attack (layer 7), and no single layer's defense covers another layer's problem. Real security means having something watching every layer — not one great lock on just one door.

Next in this series: HTTP vs HTTPS — what's actually happening during a TLS handshake, also explained without the textbook version.

I'm Nila. I write about security concepts I find interesting, in plain, everyday terms. Find me on LinkedIn.