We build an automated penetration-testing product and we sell manual penetration tests, so we have no reason to oversell either. Here's where automation genuinely works, where it needs your help, and where you still need a person.
Reliably found by automation
- Exposed files and secrets: .env and .git directories, backups, source maps, API keys shipped in JavaScript.
- Configuration weaknesses: security headers, CORS, cookie flags, TLS versions, debug endpoints left on.
- Known vulnerable components, when the version can be observed — and whether the CVE is on CISA's Known Exploited Vulnerabilities list.
- Many injection flaws (SQL, template, command) when confirmed with differential testing rather than pattern matching.
- Client-side issues such as DOM XSS traced from source to sink, and auth tokens kept in browser storage.
Found with your help
Broken access control — the classic 'change the id in the URL' bug — is invisible to a tool that doesn't know which record belongs to whom. Give an automated tester two accounts and tell it which resources each owns, and it can check whether one user can read the other's data. That's how MyPentest tests object-level authorization, and why it asks for test accounts in its deeper mode.
Still needs a human
- Business logic: applying a discount twice, refunding more than was paid, skipping a verification step.
- Chained attacks, where three low-severity issues combine into a critical one.
- Context: which data actually matters to your business, and which finding is the real risk.
- Anything that requires creativity or social context the application can't reveal.
A good automated tool tells you what it didn't cover. If a report never mentions its own limits, treat a clean result with suspicion.
How to use it well
- Run it on every release, not once a year.
- Give it test accounts so it can test access control.
- Fix the confirmed findings first; treat 'likely' ones as leads.
- Book a manual test for the logic and the high-stakes flows — with the easy findings already gone.