What Actually Stops Them: Seven Defences Worth The Cost
Knowing how intrusions happen is only useful if it changes what you build. The good news is that defence doesn't require matching an attacker technique for technique. It requires making the chain expensive to complete.
These are the controls that reliably earn their cost, roughly in order of return.
1. Know what you're running
You cannot defend an asset you've forgotten. An accurate inventory of internet-facing services, domains, and cloud resources is unglamorous and consistently the highest-value thing a small team can do. Most successful initial access happens against something nobody was watching.
Do this continuously rather than annually. Infrastructure grows between reviews.
2. Authorise on the server, every time
Broken access control tops the OWASP list because it's easy to get subtly wrong. Two rules prevent most of it:
Deny by default. Access is granted explicitly, never assumed.
Check ownership on every request that touches a specific record — not just whether the user is logged in, but whether this user may touch this object.
Hiding a control in the interface is not authorisation. The API is the security boundary.
3. Treat configuration as code
Misconfiguration rose in the 2025 OWASP revision because modern systems are largely assembled from settings — cloud policies, container definitions, feature flags, infrastructure as code. A default credential or a public bucket is a one-line mistake with unlimited consequences.
Put configuration in version control, review changes like code, and scan for the common failures automatically rather than hoping someone notices.
4. Segment, so a small failure stays small
Assume any single component will eventually be compromised, and design so that it isn't catastrophic. Service accounts get the minimum permission needed. Production credentials never appear in staging. Internal services authenticate rather than trusting network position.
This is the difference between an incident and a breach notification.
5. Manage the supply chain deliberately
The 2025 list expanded outdated components into software supply chain failures, which better reflects the risk: you inherit the security of everything you depend on, including things you never chose directly. Maintain a dependency inventory, pin versions, and have a route to patch quickly when something is disclosed.
6. Log enough to reconstruct events
Detection is where organisations lose the most time. Authentication events, authorisation failures, administrative actions and data exports should be logged centrally, stored where a compromised host can't rewrite them, and retained long enough to be useful.
Then check that someone would actually notice. An alert nobody reads is not a control.
7. Decide in advance what you'll do
Incident response written during an incident is guesswork. Decide beforehand who is called, who can take a system offline, how customers are informed, and what your legal obligations are. Then rehearse it once, badly, which is far better than never.
The honest summary
Know your attack surface.
Authorise every request server-side.
Manage configuration like code.
Segment so failures stay contained.
Track your dependencies.
Log centrally and actually read it.
Plan the response before you need it.
None of this is novel. Almost every breached organisation could recite the list. The difference is verification — whether these controls work in your environment, as deployed, today.
Block Lock assesses these controls as implemented rather than as documented, and reports what an attacker would reach in practice.
Comments