PageLens AI inspects the public surface customers, buyers, reviewers and automated scanners can see: rendered pages, forms, privacy copy, headers, cookies, network calls and public artifacts.
This is public-surface security readiness evidence, not penetration testing. Database, auth and authorization internals require a project-side review prompt or connected code workflow.
The scanner crawls, renders, inspects headers, records evidence and packages the findings for your builder, reviewer, buyer or assessor.
Forms collecting emails, payments, uploads, bookings, accounts or private messages
CSP, HSTS, frame protection and browser security headers
Insecure cookies, mixed content and weak form handling
Public source maps, secrets, stack traces and exposed files
Third-party script and SRI evidence
CORS, CORP and cache-control readiness where observable
Project-side prompts for auth, RLS, secrets, RPCs and storage internals
PageLens checks the public surface. For database, authorization and server/client separation, run this prompt inside the AI builder or repo that made the app and paste the result back into your repair workflow.
Review this AI-built app before it collects real emails, payments, uploads, private messages, bookings, accounts or customer data. Inspect all database tables, RLS policies, storage buckets, RPC functions, server actions, route handlers, API routes and Supabase client usage. Prove that users can only read or modify their own records unless explicitly intended. Flag any service-role or secret key usage in client code, any reliance on user-editable user_metadata for authorization, any security-definer function in an exposed schema, any view that bypasses RLS without security_invoker or restricted access, and any storage policy that allows unintended public read/write. For each risk, explain the data exposure consequence, the smallest safe fix, and how to verify it after deployment. Do not refactor unrelated files.
This is public-surface readiness: crawlable pages, rendered UI, screenshots, headers, cookies, storage, scripts, policies, metadata and trust signals. It is designed to turn visible risk into a clear fix list.
This is public-surface security readiness evidence, not penetration testing. Database, auth and authorization internals require a project-side review prompt or connected code workflow.
Start with the product that matches the risk you need to remove, then use the report evidence to fix issues before reviewers, buyers, customers or assessors find them.