Can someone take over an account?
Reset links that work twice, sessions that survive a password change, and second factors that can be stepped around.
web application pentest
Find what breaks after the login.
Interopt signs in as each role you give it, walks the flows your users take, and tests the API calls behind every click. Every finding carries the requests that proved it and, with your repository connected, the patch that fixes it.
GSigned in as Guest
Session outlives a password changeRefund after the order was cancelledcriticalInvite link grants admin to any signed-in userProven with the request and responseReset token accepted twiceDiscount code reused across accounts
01 / How it works
From a URL to a finding you can replay.
The scan you set up, the finding it proves, the fix it drafts and the diff on the next run.
Depth
Start with a URL. Add context when you want depth.
A public run maps what anybody can reach. Test accounts open the workflows and trust boundaries behind login. Source turns the behaviour into a file, a line and a patch.
- Black box: the public surface, from a URL
- Grey box: signed in as the test accounts you add
- White box: a paired repository read for context
Step 1
Target
app.acme.iowebapp · staging · 142 routes
Scan mode
Black-boxProbe like an outside attacker. No code access.
Grey-boxSigned-in surface, tested with the accounts you give it.
White-boxThe live target, with a paired repository read for context.
Test accounts3 logins
Each login should only see its own company's data.
Proof
A finding is the path that proves it.
Not a category and a confidence score. You get the identity, action, request and response that changed the application into an unsafe state.
- The account each request ran as
- Requests and responses in the order that mattered
- A CVSS vector and an OWASP WSTG test id
highF-2B7E90C1Password reset token accepted twice
Re-testAsset app.acme.io
EndpointPOST /api/auth/reset
CVSS 3.18.1
Observation
The token from a completed reset, replayed two hours later:
Request · Response
POST /api/auth/reset HTTP/2
{"token":"rt_91f4…","password":"••••••"}
HTTP/2 200
{"status":"password_updated"}
Signed in with the new password
Repair
The fix is part of the finding.
With the repository connected, the agent traces the proven behaviour back to its cause and drafts the change that closes it, test included. Re-test checks the finding again once it ships.
- Include or drop files, or edit the diff
- Open a pull request on GitHub, GitLab or Bitbucket
- Or download the patch and apply it yourself
2 of 2 files included · +8 −1Branch fix/reset-token-reuse · base main Reject Edit Open PR
src/auth/reset-password.ts: +2 −1
18−const reset = await findResetToken(token);
18+const reset = await claimResetToken(token); // atomic, single use
1919if (!reset) return invalidToken();
2020await updatePassword(reset.userId, password);
21+await revokeSessions(reset.userId);
src/auth/reset-password.test.tsnew+6 Download patch
Continuous
It reruns the test, not just the scanner.
Every scan retests the asset's previous findings, and the diff lines two runs up so you see what a release fixed and what it broke.
- Each finding marked resolved, new or persistent
- Recurring runs weekly, monthly, quarterly or on every deploy
- A report ready for an auditor when the run ends
Compared with the previous runSep 24New1Persistent2Resolved2
New· 1Surfaced for the first time in this scan.
criticalInvite link grants admin to any signed-in userWSTG-ATHZ-03Open
Resolved· 2Replayed by this scan and no longer reproduced.
highPassword reset token accepted twiceWSTG-ATHN-09Resolved
mediumSession survives a password changeWSTG-SESS-07Resolved
Recurring · every deployscan 7D2E4410 · 6h 18m
02 / Coverage
Test the paths, permissions, and workflows behind the interface.
The important failures sit between users, roles and steps in a workflow. Interopt tests the application as a connected system, not a collection of URLs.
Can one user act as another?
Tenant boundaries, role changes and identifiers swapped inside the browser requests the application already makes.
Can a workflow be used out of order?
Approval steps skipped, discounts reused and checkout values changed after the interface says they are final.
Can input become code?
Injection and browser execution proven by what the application did, not by a payload that merely matched a pattern.
Can your server be sent somewhere it should not go?
Uploads, webhooks and URL fields tested for the server-side requests and file access they can trigger.
What does the application reveal along the way?
Verbose errors, sensitive response fields, exposed configuration and the code path that explains the behaviour.
03 / Questions
Questions, answered.
ready when you are
Put your application in front of it.
Start with a URL. Add accounts when you want it behind the login, and source when you want the cause and the fix.