Run it as a time boxed session with a one sentence charter, such as "explore the refund flow as a user who wants more money back than they paid". Test for 60 minutes, take notes as you go, file private tickets for real problems, and spend the last ten minutes on a short debrief.
Why exploratory testing suits security
Scripted tests check what you already thought of. Security problems usually sit in what nobody thought of: odd orders of steps, unusual combinations, features used for something else. OWASP's testing guide says business logic tests need people who understand the process and its rules, and suggests testers ask questions outside conventional wisdom. An exploratory session is a structured way to ask them.
The charter
A charter has three parts. Keep it to one sentence.
- Explore: the feature or area.
- With: the tools, accounts or data.
- To discover: the kind of problem.
Examples:
- Explore the invite flow with two accounts to discover access that outlives removal.
- Explore the export function with a long list of records to discover limits that are not enforced.
- Explore the password recovery flow with an expired link to discover steps that can be skipped.
Session format
| Time | Activity |
|---|---|
| 0 to 5 min | Read the charter, set up accounts and tools |
| 5 to 50 min | Test, take notes, follow interesting leads |
| 50 to 60 min | Write up findings and open questions |
| After | Ten minute debrief with a developer or security contact |
Prompts to keep you moving
- What does this feature assume about who is calling it?
- What happens if I do the steps out of order, twice, or at the same time?
- What can I change that the screen does not let me change?
- What does the error message tell me that it should not?
- What happens when I use account A's identifier with account B?
- What is the worst thing a user could do with this, on purpose?
Notes that make a session useful
Write down what you tried, not just what you found. A line such as "tried steps 3 then 1, refused, good" tells the next tester where coverage exists. Keep timestamps, request details and the account used.
Mark items as bug, question or idea. Questions for the product owner often turn into the best abuse cases later.
Safety rules
Use test accounts and fake data. Stay inside the environment and scope agreed in advance. Do not go further than needed to show a problem, and stop when you reach real data you should not see. Report anything serious through the private channel, not the public backlog.
After the session
- File private tickets for confirmed issues, each with reproduction steps.
- Turn confirmed bugs into regression tests after the fix.
- Turn unconfirmed ideas into new charters.
- Record which areas were covered and for how long, so coverage is visible over time.
Run one session per risky feature before release, and one per quarter on older high value areas. Rotate who runs them. A fresh pair of eyes tries different things.
Try it yourself
Click through it at your own pace, or open it full screen. Follow a finding through the workflow, and think about where your session notes would feed in.
Safeguard offers a free scan for dependency findings, which pairs well with manual sessions on your own features.
Quick check
Do I need security training to run a session?
Not to start. A charter, the prompts above and a security contact for the debrief are enough for a first session.
How is this different from a penetration test?
It is shorter, run by your own team, and focused on one area. It complements a penetration test and does not replace it.
Sources
Last reviewed: 19 October 2026.
