To scan website for vulnerabilities before launch, check what attackers can reach without credentials, then verify auth, secrets, headers, and risky flows. Start with public URLs, API routes, static assets, and framework defaults. Then test logged-in behavior and payment or signup paths. The goal is not a perfect audit. It is to catch launch-blocking issues before real users and crawlers find them.
How to scan website for vulnerabilities?
A prelaunch scan should answer one practical question: can a public visitor access something they should not? For AI-built apps, the highest-risk findings are usually simple exposure mistakes, not exotic exploits.
Prioritize these checks first:
- reachable from the internet, including staging domains and preview deployments
- exposed secrets, such as .env files, API keys, tokens, and build artifacts
- unsafe default routes, including debug pages, test endpoints, and admin paths
- missing security headers, especially on auth, checkout, and dashboard pages
- broken authorization, where one user can view another user resource
A good website vulnerability scan should begin unauthenticated. Pretend you are a stranger with only the domain name. Crawl the homepage, linked pages, robots.txt, sitemap.xml, JavaScript bundles, and common static paths. Look for routes that reveal environment names, internal service URLs, object storage buckets, or privileged UI links.
Then repeat the scan with a low-privilege test account. Many launch issues only appear after login. A user dashboard might hide buttons in the UI while the API still accepts direct requests. That pattern is common in apps generated quickly from prompts because the UI and backend rules drift apart.
For deeper coverage, pair automated checks with a focused manual review. A security scan can catch public exposure quickly, while a targeted deep scan helps review more routes, headers, and application behavior before release.
Check the public attack surface
Your public attack surface is every URL, file, redirect, and API endpoint reachable from outside your team. It includes assets served by your framework, forgotten preview environments, and routes that were meant for development only.
Start with public URLs first. Test the production domain, www and non-www versions, staging subdomains, preview links, and old marketing domains. A redirect that sends users to the right place can still leak headers, cookies, or server details before the redirect completes.
Useful prelaunch targets include:
- /admin, /dashboard, /debug, /test, /api, /graphql, /swagger, /docs
- /.env, /.git/config, /config.json, /backup.zip, /db.sql
- /robots.txt, /sitemap.xml, /_next/static, /assets, /uploads
- login, signup, reset password, billing, checkout, and webhook endpoints
Run a small local sanity check before using a broader scanner:
base=https://example.com
curl -I $base
curl -s -o /dev/null -w '%{http_code}\n' $base/.env
curl -s -o /dev/null -w '%{http_code}\n' $base/.git/config
curl -s $base/robots.txt | head
curl -s $base/_next/static/BUILD_ID
curl -I $base/adminThis does not replace a scanner, but it catches surprising mistakes. If /.env returns 200, stop and rotate keys. If /admin loads without a redirect or access control, fix it before announcing the product.
For a broader outside-in view, compare your work with an external vulnerability scanner or a public attack surface scan. These checks are valuable because they see the app the way an attacker does, not the way your repository looks.
Validate secrets, auth, and headers
Secrets exposure is one of the fastest ways a small launch becomes an incident. Do not only search the repository. Inspect built JavaScript, source maps, public JSON, error responses, and network calls in the browser.
Watch for development artifacts such as stack traces, source maps, test credentials, local database URLs, and console logs containing tokens. AI-generated code often includes helpful examples that become dangerous when deployed unchanged.
Check client-side bundles for public environment variables. Public analytics IDs are usually fine. Database service role keys, payment secrets, storage write tokens, and private API keys are not. If a browser can read the value, treat it as public.
Authentication needs two layers: route protection and data protection. A page redirect is not enough. Test direct API calls for another user ID, another organization ID, and deleted or inactive accounts. If the backend trusts a userId supplied by the browser, assume it can be changed.
Use authenticated flows second after public scans. Create two test users. Log in as user A, copy an API request, then change identifiers to user B. The expected result is 403 or a filtered response. A 200 with user B data is a launch blocker.
Security headers reduce damage from browser-side attacks and misconfigurations. Review Content-Security-Policy, X-Frame-Options or frame-ancestors, Strict-Transport-Security, Referrer-Policy, and cookie flags. A security headers scan is especially useful on login and billing pages.
Use force server-side checks as the fix pattern. UI hiding is helpful for usability, not security. Authorization belongs in middleware, API handlers, row-level policies, and server-side queries. The OWASP ASVS is a useful reference for verification depth: OWASP ASVS.
Run a launch-ready checklist
A scan is only useful if it produces decisions. Before launch, define which findings block release and which can be scheduled after release. For most lean teams, exposed secrets, public admin pages, broken auth, and write-capable unauthenticated APIs should block launch.
Use this checklist during the final review:
- turn findings into tickets with URL, severity, proof, and owner
- block launch on criticals involving secrets, auth bypass, or data exposure
- Confirm every public route returns the expected status code
- Remove or protect debug, docs, seed, and test endpoints
- Rotate any secret that was exposed in logs, bundles, or public files
- Verify cookie flags: HttpOnly, Secure, SameSite, and sensible expiry
- Retest signup, login, reset password, checkout, and webhook behavior
- rerun after fixes to confirm the public app changed as expected
Severity should be based on impact, not fear. A missing header on a static marketing page is different from a missing authorization check on invoices. A public source map may be acceptable for some teams, but a source map containing internal API structure and comments about secrets deserves attention.
Keep the evidence small and useful. Each ticket should include the exact URL, request method, observed response, expected response, and suggested fix. Avoid vague tickets like improve security. Engineers fix concrete failures faster.
If you are using generated code, add one extra review pass for copied examples. Look for permissive CORS, wildcard origins, demo admin credentials, sample webhook secrets, and database policies that allow all authenticated users to read shared tables.
Ship with evidence, not guesses
Prelaunch security does not need to be slow. Cover public exposure, secrets, auth, headers, and critical user flows, then retest the fixes. The safest launch is one where the team can point to specific checks, resolved findings, and remaining risks that were accepted deliberately.
Faq
How long should a prelaunch scan take?
For a small SaaS or AI-built app, a focused first pass can take one to three hours. Budget more time if the app has payments, file uploads, team accounts, or admin tools. The fix and retest cycle often takes longer than the initial scan.
Can automated scanning replace manual review?
No. Automated scanning is excellent for exposed files, headers, common routes, and obvious misconfigurations. Manual review is still needed for authorization logic, business rules, and user-to-user data boundaries. Use both, especially before launching dashboards, billing, or private customer data.
What findings should block launch?
Block launch for exposed secrets, public admin access, authentication bypass, user data leakage, unauthenticated write endpoints, and payment flow weaknesses. Lower-risk issues, such as minor header tuning, can be scheduled if the impact is limited and the decision is documented.
If you want a fast outside-in review before shipping, run AISHIPSAFE on your production URL and fix the launch-blocking findings first.