What can a public app security review verify?
A public review can inspect the pages, HTTP responses and browser files an ordinary visitor receives. It can record an exposed file or a missing browser control. A clean public result cannot show that logged in customers' data is separated, or that payment handling is safe. OWASP's Web Security Testing Guide treats public information gathering as one part of application testing. This brief sets out where that evidence stops.
Josh, published 29 September 2026
The claim must fit the access
A finding is useful when it says what was observed and what remains unknown.
Public access is enough to check a particular page response, the files it serves and the behaviour visible without an account. That can uncover a concrete problem. A browser asset containing a credential pattern, for example, deserves investigation. The pattern alone does not establish whether the credential is live or what it can reach. OWASP WSTG-INFO-05 covers this kind of public information leakage.
A clean result is narrower. It means the reviewer found no issue in the pages, files and states examined. It says nothing conclusive about a hidden route, a second account or a server setting the reviewer could not see. OWASP ASVS describes web application security verification as a broader set of technical controls.
How to read a finding
Evidence rule- Observed. Name the page, file, response or visible action.
- Implication. Explain the plausible risk without claiming an exploit was proved.
- Next check. Say what access or test would resolve the uncertainty.
- Limit. Record what was outside scope.
You can inspect what the browser receives
A public URL supports a finding about that observed surface.
An external reviewer can inspect HTTPS behaviour, response headers, visible errors, page content and files served to the browser. OWASP's HSTS testing guide shows how to confirm the presence and value of one header from a response. Its information leakage guide covers page comments, JavaScript and public source maps.
Those checks can support a direct statement such as a named response lacking a named header. They cannot prove the same header is absent everywhere. A header may also be present but poorly configured. The finding needs the observed URL and a check of what the value actually does.
Publicly visible source maps and browser code can help identify exposed information. They do not, by themselves, show the reviewer the server's complete source code. A string that resembles a private key needs validation and, if it is a live secret, a safe response by the app owner.
Example wording
Illustrative- Supported. The HTTPS response for [observed URL] did not include a Strict-Transport-Security header when checked.
- Unsupported. The entire application is insecure because one header was absent.
A login screen does not test permission
Testing separation between accounts needs authorised test users and relevant roles.
A visitor can see whether a login page exists. That does not show whether a customer can reach another customer's records after signing in. OWASP WSTG-ATHZ-02 describes comparing requests across users with the same role and across users with different roles. It also checks whether protected resources are available without signing in.
That work needs an agreed test scope and suitable accounts. Without them, a public reviewer cannot honestly mark private account separation as passed. A public route that leaks data may still be found, but the absence of such a leak is not proof that every private route is controlled.
Question to put to the developer
Access check- Can one test customer retrieve another test customer's record?
- Can a regular user call a function reserved for an administrator?
- Are those checks enforced by the server or data service, rather than only hidden in the interface?
Private logic needs private access
The browser sees the result of server work, not every rule behind it.
Public responses may expose a specific failure, but ordinarily do not establish how server validation, database permissions, dependencies or secret handling are implemented. Testing with authorised accounts can probe some private behaviour. Reviewing implementation also needs appropriate code and configuration access. OWASP's secure code review guidance describes manual code review as complementary to automated security testing, including dynamic tests.
Source access does not make a review complete by itself. The reviewer still needs to understand how the app runs and test relevant behaviour. The point is to match the evidence to the decision. A public result can flag work for the developer. It cannot certify the code or configuration it never inspected.
What each access level adds
Scope map- Public URL. What an unauthenticated visitor receives.
- Test accounts. Selected requests and permissions across users and roles.
- Code and settings. How server logic and private controls are implemented.
Start with the question you need answered
A public review is useful for visible problems and launch triage. Deeper decisions need deeper access.
If a public staging page is ready and you want to know what an ordinary visitor can reach, start with an external review. VibeZero's free public app review is a manual, read only assessment of unauthenticated pages. It covers visible security signals alongside usability, accessibility, loading and search. A senior engineer sends a plain English PDF within 24 calendar hours after receiving a working public URL. It is not a penetration test or a security certification.
If the launch decision depends on accounts, private customer data, payments or private server controls, arrange an appropriately scoped review with the access needed to inspect them. VibeZero's paid app audit is a separate decision, with scope and price agreed first. The free public PDF can help identify questions for that work, but it does not substitute for it.
For an owner's practical launch checks, read the AI built app security checklist before launch. For published results on AI generated code, see the separate vibe coded app security research brief.
Ask for a report that says
Review standard- Which pages, accounts and systems were in scope.
- What the reviewer observed and how to reproduce it safely.
- Which claims remain untested and what access would resolve them.
Questions about public app scans
No. A public scan can report findings on the pages and files it observed. It cannot establish the safety of logged in workflows, other users' data, server code, storage rules or private configuration. A clean public result means no issue was found in that limited view.
Testing guidance behind the boundary
Check the visible app