What we actually find: recurring patterns from our engagements

After a decade of engagements across web applications, APIs, mobile, cloud, internal networks and red teams, the findings stop looking random. The specifics change; the root causes don't. This is an honest, qualitative look at the patterns we see most often — not a lab study, but what recurs across real client work, anonymised. If you only fixed the classes below, you'd close the large majority of what we report.

1. The worst findings are credential-handling, not clever exploits

Our highest-severity findings rarely come from exotic vulnerabilities. They come from secrets in the wrong place: hardcoded credentials shipped inside mobile apps, signing keys readable by the application that uses them, database accounts with far more privilege than the app needs, service accounts whose passwords haven't changed in years. None of these require a novel exploit. All of them can end an engagement in an afternoon.

Takeaway: a secrets-management and privilege review is often higher-value than another round of code-level testing.

2. Access control is still the number-one application bug class

Broken object-level authorization (IDOR/BOLA), roles that grant more than their label suggests, and operations with no server-side authorization check appear in nearly every application test. The pattern is almost always the same: the UI enforces the rule, the server assumes the UI did. Attackers don't use the UI.

Takeaway: every object access and every mutating operation needs a server-side ownership and role check. Add these as automated tests, not manual reminders.

3. "Hardened" and "finished" are different things

Plenty of the apps we test are genuinely well-built against injection and classic web bugs — and still fail on design. Missing segregation of duties on high-impact operations (one operator able to move or halt payments alone), data exports that execute as spreadsheet formulas on the opener's machine, workflows that trust client-supplied status and dates. The defences are real; the business logic underneath them isn't tested the same way.

Takeaway: ask your testers explicitly to probe business logic and segregation of duties, not just the OWASP Top 10.

4. Tokens live too long and travel too far

OAuth and session handling is a recurring source of high-severity findings: long-lived tokens returned in URLs or embedded in page scripts, tokens not revoked on logout, password grants left enabled on public clients. One long-lived token exposed in one place often means a full day of access to whatever it protects.

Takeaway: authorization-code + PKCE, short lifetimes, server-side revocation, and never a token in a URL or a JavaScript global.

5. Active Directory falls to hygiene, not zero-days

On internal and red-team work, the path to Domain Admin is almost always a chain of hygiene failures: Kerberoastable service accounts with ancient passwords, AS-REP-roastable accounts, unsigned SMB/LDAP enabling relay, stale never-expiring admins. We've written about the BloodHound view of this; the point here is that the fixes are configuration, not patching.

Takeaway: privileged-account hygiene and signing/relay hardening cut more real risk than almost anything else internally.

The good news we also report

It's worth saying plainly: not every engagement is a horror story. We've tested external perimeters that were genuinely tight, web apps that produced only low-severity findings, and banks whose phishing defences, staff awareness and network segmentation all held under a real red team. We report those results just as carefully — a clean finding, independently verified, is evidence worth having. Honest reporting includes the good news.

Where this says to spend

1. Secrets and privilege — where your worst findings come from.
2. Server-side authorization — on every object and every action.
3. Business logic and segregation of duties — the gaps scanners never see.
4. Token lifecycle — short, server-revocable, never in URLs.
5. AD hygiene — the cheapest high-impact internal wins.

None of this is new, and that's the point. The attackers winning today aren't using tomorrow's techniques; they're using the same five root causes we find every month.