Network Security Cheat Sheet

The OSI model is useful as a network security checklist because each layer introduces a different trust boundary. An attack at one layer often bypasses controls at another. A clean application security review can still miss ARP spoofing on a flat office network, and excellent switch hardening does not help if an API accepts forged requests. The point of a cheatsheet is not to memorise attack names. It is to know where a failure can happen and which control belongs there.

Application and session layers

At the top of the stack, attackers target business logic and user trust. Common examples are phishing, credential theft, weak password reset flows, broken authorisation, and application-layer denial of service. These attacks look legitimate to lower network layers because the packets themselves are well formed. Defences therefore live close to the application: strong authentication, rate limiting, input validation, safe file handling, and detailed request logging.

The session layer is where identity continuity breaks down. Session fixation, token theft, replay, and credential stuffing all exploit the fact that a server needs a stable way to recognise the caller across requests. Good controls here include short-lived tokens, secure cookie flags, device or risk signals, multi-factor authentication, and server-side invalidation when a user logs out or changes credentials. The operational constraint is that tighter controls create more friction, so teams need to decide where extra login prompts are worth the drop in attack surface.

Presentation and transport layers

The presentation layer often disappears from simplified diagrams, but it matters whenever a system parses structured data or transforms it between formats. Unsafe deserialisation, parser differentials, decompression bombs, and content-type confusion can all start here. If two services interpret the same payload differently, one may accept data that another downstream component treats as executable or privileged.

The transport layer is where confidentiality and connection state are protected. Man in the middle attacks, downgrade attempts, SYN floods, and protocol abuse all show up here. TLS is the obvious defence, but only when certificate validation, key rotation, supported cipher policy, and protocol versions are all managed properly. A team that says "we use TLS" still has work to do around certificate expiry, internal service trust, and whether legacy clients force weaker settings.

Network and data link layers

At the network layer, the main issues are spoofing, route manipulation, and volumetric denial of service. IP addresses tell routers where to send packets, so any design that trusts source addresses too much is fragile. Segmentation, anti-spoofing filters, route validation, and upstream DDoS mitigation reduce the blast radius. In cloud environments, security groups, network ACLs, and route tables are practical expressions of these controls.

The data link layer governs local network assumptions. ARP spoofing, MAC flooding, VLAN hopping, and rogue DHCP responses are all possible when endpoints share a broadcast domain. These attacks matter because many systems still assume that "inside the office" means trusted. Switch port security, DHCP snooping, dynamic ARP inspection, and tighter VLAN design address that assumption directly.

Physical layer and operating reality

At the physical layer, the attack is often boring and effective: unplug a device, steal a laptop, attach a hardware implant, or connect to an exposed console port. Software teams sometimes forget that a strong protocol can be defeated by weak cabinet locks or unmanaged branch-office equipment.

A practical network security review therefore walks the stack from top to bottom and asks four questions at each layer: what asset is exposed, what trust assumption exists, how could it fail, and which control is closest to that failure? That habit is more useful than any static list of attack names because real incidents usually cross several layers at once.