# LaunchGlint deep scan report

Target: https://example-ai-app.com
Score: 54/100 (F)
Scan mode: Owner launch scan
Status: Sample artifact - no live app was assessed

## Executive summary

This sample shows the structure of the Markdown artifact delivered after a paid LaunchGlint scan. The example app has one critical secret-exposure finding and one medium Supabase review finding. Fix the critical issue before sending traffic or accepting payments.

## Severity summary

- Critical: 1
- High: 0
- Medium: 1
- Low: 0

## Findings

### 1. Possible live Stripe secret key exposed

- Severity: Critical
- Category: Secrets
- Evidence: Matched a known high-risk token pattern in public HTML or bundled client code.
- Fix direction: Immediately rotate the exposed Stripe key, remove it from client code, and move all secret-key Stripe calls to the server.

#### AI-coder prompt

```text
You are fixing a pre-launch risk in this app.

Finding severity: critical
Finding category: secrets
Evidence: Matched a known high-risk token pattern in public HTML or bundled client code.

Task:
1. Remove the exposed Stripe secret key from every browser bundle and public file.
2. Rotate the affected key in Stripe before redeploying.
3. Move secret-key Stripe operations to a trusted server endpoint.
4. Add a regression check that fails the production build when a live secret-key pattern is present.

After changing code or configuration, explain exactly how to verify the fix on the deployed URL.
```

### 2. Supabase project URL is visible

- Severity: Medium
- Category: Data access
- Evidence: The client bundle references a Supabase project.
- Fix direction: Confirm that every exposed table and Storage bucket has least-privilege policies. A publishable or legacy anon key is not automatically a secret, but a service-role key must never reach the browser.

#### AI-coder prompt

```text
Audit this Supabase-backed app before launch.

1. List every table and Storage bucket reachable by anonymous and authenticated roles.
2. Confirm Row Level Security is enabled on every exposed table.
3. Test with two ordinary users and prove neither can read, update, or delete the other's private records.
4. Confirm no service-role or secret key is present in browser code, source maps, or public configuration.
5. Record the exact test requests and expected allow/deny results.
```

## Deployment playbook

### Firebase Hosting

1. Remove secret values from frontend environment variables and generated bundles.
2. Put server-only payment logic behind Cloud Run or another trusted backend.
3. Add required response-header rules to `firebase.json`.
4. Deploy Hosting and Cloud Run.
5. Inspect the real production response and browser bundle, not only localhost.
6. Rescan the exact `web.app` or custom-domain URL.

## Launch checklist

- [ ] Rotate every secret that may have been public.
- [ ] Verify the production bundle no longer contains the old value.
- [ ] Test database and Storage access with anonymous, user A, and user B sessions.
- [ ] Confirm HTTPS, indexing, security headers, privacy, terms, support, and refund paths.
- [ ] Complete a real low-value checkout and verify automatic report or product delivery.
- [ ] Rescan after deployment and keep the before/after score.

## Scope

LaunchGlint uses public GET requests and public response evidence. It is not a pentest, compliance audit, certification, legal opinion, or guarantee that an application is secure.
