5.4 The attacks you will actually meet, and the defences

What this is and why it exists

The previous topic listed how accounts get compromised. This one goes a layer down into the attacks themselves — what each actually does, where in your architecture it lands, and which specific layer stops it. The skill being built is precise: not "we have security", but "that attack arrives here, and this is what refuses it".

The vocabulary

• Denial of service (DoS) — making a service unavailable by consuming something it needs; distributed (DDoS) means from many sources at once.
• Volumetric attack — one that tries to fill your bandwidth; an application-layer attack sends few but expensive requests.
• Rate limiting — refusing requests beyond a stated rate per client.
• Web application firewall (WAF) — a filter that inspects HTTP requests and blocks patterns.
• Injection — untrusted input reaching an interpreter, which then executes part of it as instructions.
• Broken access control — the application checking who you are but not whether this particular record is yours.
• Image provenance — knowing where a machine or container image came from and what is in it.
• Data classification — deciding, in advance, which of your data is sensitive and to what degree.

The mental model

Denial of service comes in two shapes and they are stopped in different places. A volumetric flood tries to exhaust bandwidth, and no origin server absorbs it; it is absorbed at the edge, by a CDN or a scrubbing service with far more capacity than any attacker's target. An application-layer attack is quieter and more common at small scale: a few hundred requests per second to your most expensive endpoint — a search, a report, a sign-up that sends an email — which is trivial to send and costly to serve. Rate limiting at the edge is the answer, per client and per endpoint, with the expensive routes limited hardest. And there is a cost dimension people miss: with autoscaling on, an attack you successfully absorb is an attack you paid for. A spending alert is part of your denial-of-service defence.

Firewalls in the cloud are three layers, each seeing something different. Security groups see addresses, ports and protocols — they decide whether a connection may exist at all. A network firewall sits at the boundary and can see more of the traffic, including outbound destinations, which is where exfiltration is caught. A web application firewall sees the HTTP request itself: the path, the headers, the body, so it can refuse an injection pattern or a known-bad signature. Each is blind to the layers above it, which is the whole reason there are three, and none of them fixes an application flaw — a WAF buys you time to deploy a fix, and a team that treats it as the fix has bought a delay and called it a repair.

Application security is where the majority of real incidents actually begin, and two failures dominate. Injection happens when untrusted input reaches an interpreter that then treats part of it as instructions — the database, the shell, a template engine. The reliable defence is not filtering the input but never mixing it with the instruction: parameterised queries, arguments passed as a list rather than a string, escaping at the point of output. Broken access control is the more embarrassing one: the application authenticates you correctly and then serves record 1234 because you asked for it, without ever checking that record 1234 is yours. It is invisible to scanners, it does not look like a bug in testing where everyone uses their own data, and it is found by changing an identifier in a request and seeing what comes back. The third member of the family is the dependency nobody audited — a library pulled in transitively, with a known vulnerability, updated by nobody. That one is solved by tooling: scan dependencies in the pipeline and treat a failing scan as a failing build.

Machine security is mostly about where images come from. An image is a filesystem somebody assembled, and running one you did not build from a source you cannot name is executing a stranger's code with your permissions. So: pull base images from official sources, pin them to a digest rather than a moving tag, scan them, and rebuild on a schedule so that patched bases actually reach production. Patching running machines instead is the habit that produces servers nobody dares restart. As for the escape scenario — a workload breaking out of its container or virtual machine into the host — it is genuinely rare, and the honest framing is that it is the provider's problem for virtual machines and a shared one for containers, which is why a container running as root with unnecessary capabilities is worth fixing even though the escape itself is unlikely.

Data security is the last layer and the one that decides how bad any of the above turns out to be. Classify first, because you cannot protect uniformly what you have not sorted: which stores hold personal data, which hold credentials, which hold things that would merely be embarrassing. Encrypt according to that, log access to the sensitive ones — reads as well as writes, because reads are how data leaves — and then confront deletion honestly. Deleting a row does not delete it from last night's backup, from the replica, from the analytics warehouse it was copied into, or from the log line that recorded it. Deletion that is actually deletion is a design decision made in advance: know every copy, set retention on each, and be able to say where a person's data lives before somebody asks you to remove it.

What you should now be able to explain or do

Distinguish volumetric from application-layer denial of service and say where each is stopped. Explain why a spending alert is part of a denial-of-service defence. Name the three firewall layers and what each can see. Explain why parameterised queries beat input filtering. Describe how you would test for broken access control in ten minutes. Say what pinning an image to a digest prevents. List every place a deleted record might still exist.

Check yourself