The product

Find it. Understand it.
Review the fix. Verify again.

01

Start with the evidence

See the affected endpoint, what the scanner observed and why it matters. Here is an example of how to work through a data-access finding.

demo.exampleIllustrative example
HIGHPrivate profile returned without a login

Only the profile owner should be able to read this email.

[{"id":"demo-001","email":"person@example.com"}]

A request using a public client key and no user session returned a profile row. The returned data, not the 200 status alone, is the evidence.

Illustrative example with fictional data, not a customer scan.

02

Bring the finding to your coding tool

Choose Export for AI in your report. Give your tool the evidence and intended permissions, then review its proposed change and tests.

Example review request

Review this finding against my app. Check table grants, RLS and existing policies. Propose a change that preserves owner access and blocks other readers. Add tests with disposable data. Show the diff before applying it.

You approve the change. VAS does not apply it.
03

Verify the deployed change

Rescan after deployment and repeat permission tests. For this example, check all three access paths below. On Pro, weekly monitoring can notify you about changes found during scheduled checks.

Signed out: the private test profile is not returned.
Profile owner: the intended profile is still readable.
Different user: the private test profile is not returned.