SHIPSAFE guides / Guide

Developer guide

Pre-release security checklist for apps built with AI coding tools

AI coding tools write working code fast, and they also copy patterns that should never reach production: inline keys, debug switches, open routes. This checklist is about reading what was generated before users get it.

By Ilyas A. Almadani · Updated October 22, 2026 · Steps checked against the vendors' official documentation, linked at the end

The short version
  1. Secrets: none in code, none in git, all revoked if they ever were.
  2. Config: debug and development settings off in what you deploy.
  3. Access: every admin or sensitive route checks who is calling.
  4. Dependencies: pinned, with a lockfile, reviewed.
  5. Logs and leftovers: no secrets in output, no stray TODOs.

This is a checklist, not a guarantee. It reduces the common, avoidable mistakes. It does not replace testing, a security review for sensitive apps, or the provider's own guidance.

1. Secrets

  • Search the project for key formats and words like secret, token, password and apikey. Check config files and tests too.
  • Confirm .env and similar files are in .gitignore and not tracked: git ls-files | grep -i env.
  • Look at git history for secrets that were committed and removed. See removing a .env file from git history.
  • If any real key ever appeared in code, a prompt, a screenshot or a commit, rotate it. See the first-hour plan.
  • No secret keys in a mobile or browser app. See hard-coded keys in iOS apps.

2. Debug and development settings

  • Debug mode, verbose error pages and development environment flags are off in the deployed configuration.
  • No localhost URLs in deployable config.
  • TLS verification is not disabled anywhere (look for options that skip certificate checks).
  • Session cookies use the Secure and HttpOnly flags.
  • CORS does not allow every origin (*) for an API that uses cookies or tokens.
  • iOS: App Transport Security is not switched off. See ATS exceptions. The Release build does not carry the get-task-allow debug entitlement or a development push environment.

3. Who can call what

  • List every route. For each admin, billing, export or delete route, find the line that checks the caller's identity and permission.
  • AI-generated endpoints often check that a user is signed in but not that the record belongs to them. Test with two accounts.
  • If you use Supabase or Firebase, confirm Row Level Security or Security Rules are on. See which keys are safe and what protects the data.

4. Data and input

  • Database queries use parameters, not strings built from user input.
  • Migrations you are about to run do not drop or truncate data by accident. Read generated migrations before applying them to production.
  • Error responses do not return stack traces, SQL or environment details.

5. Dependencies

  • A lockfile is committed, so installs are repeatable.
  • Check that every package the AI tool added is real, maintained and the one you meant. Look for slightly misspelled names.
  • Run your package manager's audit command and read the output.
  • Remove packages you do not use.
Run the mechanical parts automatically

Much of this list can be checked by a scanner. SHIPSAFE for Mac scans a project folder locally and reports hard-coded secrets, debug and development settings left on, admin and sensitive routes without an evident authentication guard, risky dependency versions and missing lockfiles, destructive database migrations, injection risks, and leftover TODOs and console logging, each with file, line and a suggested fix. It is a review assistant: findings can include false positives or miss context, so you still make the release decision. Mac App Store page.

6. Logs and leftovers

  • Remove console.log, print and debug output that prints tokens, passwords or full request bodies.
  • Resolve or delete TODO and FIXME comments that mark skipped security work, such as "add auth later".
  • Delete test accounts, seed data and sample admin users.

7. Final steps before you ship

  1. Build the release configuration, not the debug one, and test it.
  2. Set spend limits on every paid API the app uses. See AI API keys: spend limits.
  3. Turn on push protection in your repository so the next secret is blocked at push time.
  4. Write down how to revoke each key you use, so a leak is a five-minute job.

A scan or a checklist cannot guarantee that software is secure, compliant or accepted by any store. Use them to catch the obvious problems early.

Frequently asked questions

Is AI-generated code less secure than hand-written code?

Not automatically, but it is often written without your production context. It tends to include inline keys, debug flags and unprotected routes, so it needs the same review as any code from a new contributor.

What is the single most important check before release?

Make sure no secret key is in the code, the repository history or the shipped app, and that any key that ever leaked has been revoked.

Does a clean scan mean my app is secure?

No. A scan catches known patterns and common release mistakes. It cannot prove the absence of bugs, so combine it with testing and review.

Official documentation used for this guide

Vendor interfaces change. If a menu looks different, follow the linked documentation.

More guides

See all SHIPSAFE guides

Check your project before the next release

SHIPSAFE scans a project folder on your Mac for leaked keys and risky release settings, and shows the file, the line and a suggested fix for each finding. It runs 100% locally, with no upload and no account. It is a review assistant, not a guarantee of security.

SHIPSAFE findings list showing the file, line and evidence for each issue