Ran a lot of pentests for early-stage startups prepping for SOC2. Same five findings show up almost every single time:

1. IDOR on internal APIs — object IDs are sequential or guessable, and auth checks only validate "is logged in," not "is this YOUR resource." This is the #1 finding, by far.

2. Stale admin panels — an internal tool from 8 months ago, still deployed, still has default or weak creds, forgotten by everyone except the attacker who finds it via subdomain enumeration.

3. Overly permissive S3/GCS buckets — usually from a quick "just make it public for now" fix that never got reverted.

4. Secrets in client-side bundles — API keys or internal service URLs shipped straight to the browser because an env var got prefixed wrong (NEXTPUBLIC, VITE_, etc.)

5. No rate limiting on auth endpoints — login, password reset, and invite endpoints accept unlimited attempts, making credential stuffing trivial.

The pattern: none of these are exotic. Auditors and attackers both know to check for exactly this. If you're prepping for SOC2 Type 1 or 2 and haven't had a real pentest yet, run through this list against your own stack first — it'll catch 70-80% of what a real test finds, for free.

Happy to answer questions on scoping a first pentest or what auditors actually expect to see in the report.