Sample reportSee a full audit on synthetic data

Know before you ship.

Security audits for apps built with AI coding tools. Find leaked keys and broken access control, then get redacted proof and the fix.

Scan my app See a sample report

Read-only by default
Domain verification first
Evidence deleted after 30 days

example-app.test/Scans/Launch audit

Search findings⌘K

Illustrative Completed Re-run scan

Readiness64/100

Proven2High severity

Suspected0Needs confirmation

Untested1Write replay

FindingsAll 4Failed 2Untested 1

SeverityFindingStatus

HighProfiles readable without signing inGET /rest/v1/profilesProven

HighUser B can read A’s profileGET /rest/v1/profiles?id=eq.aProven

—Write replayNo staging scope suppliedUntested

PassNo secrets in client bundleassets/index.jsPassed

EvidenceHigh · Proven

Profiles readable without signing in

REQUEST  GET /rest/v1/profiles
SESSION  logged out · anon key
RESPONSE 200 · 3 rows
SAMPLE   a***@example.test

LovableBoltCursorClaude Code

Repair the authorization of the profiles table. Allow a user to read only their own row using auth.uid()

Copy fix prompt

For apps built with the tools you already use

Supported workflows, not partnerships.

Lovable
Bolt
v0
Replit
Cursor
Claude Code
Supabase

GET/the-problem200

Your app works. That doesn’t mean it’s safe.

AI coding tools ship features fast, but they rarely check who can read what. These are the four leaks OkToShip looks for, and what a proven finding looks like.

assets/index-4f1c.jsClient bundle

12import { createClient } from "@supabase/supabase-js";

14export const supabase = createClient(

15 "https://example.supabase.co",

16 "eyJhbGciOiJIUzI1NiIs••••••••••••"service_role key in the client bundle

17);

Critical · Proven

Anyone who opens the app can copy a key that skips every database rule.

Fix

Rotate the key, move privileged calls server-side and ship only the public anon key.

GET/how-it-works200

From consent to a fix in four steps.

Scoped to what you authorize and read-only by default. Scroll through one audit from start to finish.

01 Authorize

Prove you own it before anything runs.

Verify the domain with a DNS TXT record or meta tag, connect source through the read-only GitHub App or a ZIP, and attest the Supabase backend. Each scan records consent and scope.

Domain verification Verified

Type: TXT
Host: example-app.test
Value: oktoship-verify=9f2c…e71a

Consent & scope

I own or am authorized to test this app
Scope: example-app.test, test accounts A and B
Read-only requests unless staging opt-in

02 Scan

Check what actually ships to a browser.

Client bundles, source, Supabase policies, storage buckets, headers and dependencies are checked. Requests are bounded, rate-limited and read-only by default.

Launch audit · example-app.testRunning

Client bundles
Source · read-only
Supabase policies
Security headers
Dependencies

03 Prove

Replay the read as somebody else.

Two dedicated test accounts and synthetic rows. A’s request is replayed as User B and as a logged-out visitor. Successful access becomes a finding; ambiguous ownership stays untested.

Replay · GET /rest/v1/profiles?id=eq.a

User AOwner200Expected

User BOther account200Should be denied

Logged outAnon key200Should be denied

2 proven findings · write replay untested

04 Fix

Take a specific repair back to your tool.

Every finding comes with redacted evidence and a fix prompt for Lovable, Bolt, Cursor or Claude Code. Apply it, then run the same checks again.

LovableBoltCursorClaude Code

Repair the authorization of the profiles table. A logged-out GET returned 3 rows and User B read the row owned by User A. Allow a user to read only their own profile using the actual owner column and auth.uid(). Add tests for A, B and logged-out access.

Copy fix prompt Secrets omitted

example-app.test · Launch audit01 · Authorize

Domain verification Verified

Type: TXT
Host: example-app.test
Value: oktoship-verify=9f2c…e71a

Consent & scope

I own or am authorized to test this app
Scope: example-app.test, test accounts A and B
Read-only requests unless staging opt-in

Launch audit · example-app.testRunning

Client bundles
Source · read-only
Supabase policies
Security headers
Dependencies

Replay · GET /rest/v1/profiles?id=eq.a

User AOwner200Expected

User BOther account200Should be denied

Logged outAnon key200Should be denied

2 proven findings · write replay untested

LovableBoltCursorClaude Code

Copy fix prompt Secrets omitted

GET/what-you-get200

Proof you can act on.

Every report pairs a finding with its evidence and a repair, so you know what broke, why it matters and what to change.

Readiness score

A number you can explain.

0–100, built from proven findings and capped when coverage is incomplete. Untested checks are never counted as passes.

64/100

Proven 2
Suspected 0
Untested 1
Coverage 4 of 5 checks

Redacted evidence

The request, and what came back.

GET /rest/v1/profiles
session   logged out
status    200 · 3 rows
sample    a***@example.test
secrets   omitted

Fix prompts

Paste the repair into your tool.

In Lovable, repair the profiles policy. Allow a user to read only their own row with auth.uid(), then add tests for A, B and logged-out access.

Shareable report

A PDF you can hand to anyone.

Findings, coverage and fixes in one redacted document for your team, your client or your next launch review.

Open the sample report PDF

GET/safety200

Built to test, never to break.

An audit should never become the incident. Here is what happens to your app and your data at every step.

01
Verify ownership
DNS TXT or meta-tag proof for the exact origin. Valid for 30 days, rechecked before every request.
02
Scan read-only
Bounded, rate-limited requests. Only designated test data is touched.
03
Mask secrets
Matched values are masked before storage, logs or reports, and never reused.
04
Report with proof
Every result is proven, suspected or untested. Untested is never a pass.
05
Delete evidence
Evidence is encrypted and scheduled for deletion after 30 days.

Never asks for a service_role key
No injection or brute-force payloads
Writes only on staging, with consent
A 200 response alone is never a finding

How we handle data

For agencies

Hand every client a clear audit record.

One project per client app. Record the authorization, audit the prepared app, and deliver a redacted PDF that explains what ran, what failed and what to fix.

01 Record the authorization
02 Audit with two test accounts
03 Hand over the report and prompts

See the agency workflow

A small team discussing their app in an office

Redacted PDF · one project per client

GET/pricing200

Start free. Pay for the proof.

A free summary shows where to look. A Launch Audit or Builder plan opens every finding, the PDF and fix prompts.

Compare every plan

Free

See where your app needs a closer look.

$0Summary only

Start with a summary

Readiness score and coverage
Finding counts by severity
Verified, authorized targets

Launch Audit

Full report

Get the evidence before your next launch.

$49One-time · one audit

Audit my app

Full findings and redacted proof
Web report and downloadable PDF
Fix prompts for your coding tool
Link source and Supabase inputs

Builder

Come back after your app changes.

$29per month

Create a workspace

Full reports on repeat scans
Scheduled monitoring and Slack or email alerts
Client portals and white-label PDFs
CI quality gate and fix pull requests
Cancel your subscription anytime

Prices in USD
Cancel Builder renewal from your dashboard
Evidence deleted after 30 days
A summary is always free

GET/faq200

Questions, answered.

What teams usually ask before their first audit.

Read the documentation

Is it safe to scan a production app?

Verified production targets support bounded reads of test-owned data. Write replays need staging, disposable test rows and explicit consent. Anything else stays untested.

What do I need for my first audit?

An app you own or are authorized to test. Add its URL and verify the domain, then optionally connect source through the read-only GitHub App or a ZIP, plus a Supabase metadata export.

Do you need my Supabase service_role key?

No. Provide a read-only audit connection or the SQL metadata export. Never paste a service_role key into OkToShip or into client code.

What does the score guarantee?

Nothing beyond the checks that ran. Read findings and coverage together. A clean scan is not a guarantee that an app is safe.

How long is evidence kept?

Evidence is encrypted and scheduled for deletion after 30 days. Download the report while it is available.

Which tools get fix prompts?

Lovable, Bolt, Cursor and Claude Code. The explanation service sees bounded, redacted finding data and is used only for wording, never for detection.

GET/field-notes200