We're getting a web app pentest done but want to prep first — is there a checklist we can run through ourselves?

Last year we paid £5,000 for a pentest on a similar B2B app. Because we didn't do any prep, 14 out of the 22 findings in the report were just missing HTTP headers and default server banners. It was painful realizing at least £1,500 worth of the consultant's time went into reporting complete basics.

The single most critical thing is environment stability. Never point them at production; set up a dedicated staging server seeded with an anonymized dump of real data. That way, when the tester runs payloads that corrupt the DB or flood your queues, live operations won't go down. Also, put a strict deploy freeze on the staging environment for the entire duration of the test.

Double-check input validation and cryptography. Make sure special characters are properly escaped across all form inputs and URL parameters. Ensure every piece of user input saved to the database is sanitized, and confirm session tokens are properly invalidated server-side upon logout. Gaps in these areas will immediately drag down your test results.

Don't oversimplify the staging setup trying to make everything friction-free. Sometimes devs drop the firewall completely or turn off protection layers just to make the testers' lives easier. Then the app gets a clean report, goes live, and gets hacked immediately. The test environment must be a 1:1 mirror of production.

Give the testers two valid accounts for each role: two standard users and two admins. Also throw in a demo account with strictly limited permissions. That allows them to test privilege escalation and IDOR horizontally between users right from hour one without roadblocks.

Is your scope white-box or black-box? If you're handing over source code and API schemas closing documentation gaps should be your top priority during prep. If you aren't giving them code access put all your focus on hardening externally exposed endpoints.

You have the exact right mindset here. Doing your own prep also massively levels up the dev team's security awareness. If you run a half-day internal workshop to review the OWASP Top 10 directly against your codebase, you'll get the absolute most out of the engagement.

definitely whitelist their ip on the firewall. during our pentest the tester got blocked completely on day one and they wasted half a day sending emails back and forth just to get unbanned, total waste of money.

I agree.

The opposite happened to me, that's why I'm writing. Solutions that work at a small scale collapse when you grow; I learned this late.

The harder it is to reverse a decision the slower you should make it. Proven by experience.

If you're going this route, sort this out first. Processes without records never improve, because you don't know what to fix.

This is my opinion, I'm not claiming it's absolute truth.

Let me summarize what's been said so far. An automated scan report is not the same as a penetration test.

Good luck with that.

This thread is archived.

Heres how it went for us. If you dont write this down from the start it leads to arguments later.

Forgotten test environments are more often the entry point than live systems. If you post the result here, it will help others too.

I think differently. When we decide without measuring, we always end up in the same place.

An untested backup is not a backup. If you have questions, write them; I'll answer as best I can.

I have no experience with web app pentest, so I'm asking. Having backups accessible on the same network and with the same identity makes them part of the target.

If you have questions, write them; I'll answer as best I can.

Timely topic.

My question might sound amateurish, sorry about that. Most incidents start with a leaked password, not a vulnerability.