Vibe-Coded App Security Checks Before Launch: Free Open-Source Tools

Before a vibe-coded app goes live, run four checks: no secret keys in the code or its history, database access limited to the right users, no packages with known vulnerabilities, and no obvious holes in the running site. Free open-source tools cover each one, and together they take an afternoon, not a week.

AI coding tools can produce a working app fast. They are less careful about what happens when a stranger, not you, starts poking at it. This guide is for UAE founders and small teams who built something with Cursor, Claude Code, Lovable, Bolt or similar tools and want a sensible security pass before sharing the link with customers. It sits alongside our earlier guide to what vibe coding is and where it breaks.

Why AI-built apps need a separate security pass

An AI assistant writes code that makes the feature work. It does not know which data is sensitive to your business, who should be allowed to see it, or which keys must never reach the browser. Common gaps in AI-generated projects are predictable:

• API keys pasted straight into the code so the demo works.
• Database tables that any visitor can read through the public API.
• Old or abandoned packages pulled in without a second look.
• Admin pages and test routes that were never removed.
• Forms that accept anything and pass it on without checks.

None of these show up when you click through the app yourself. They show up when someone looks for them, which is why a short, repeatable checklist helps.

Step 1: find leaked secrets with Gitleaks

Gitleaks (MIT licence) describes itself in its README as a tool for detecting secrets like passwords, API keys and tokens in git repos and files. It scans the current files and the full commit history, which matters because a key you deleted last week still sits in an older commit.

1. Install it (Homebrew, Docker or a release binary, as listed in the README).
2. Run gitleaks git -v inside your project to scan the history, or gitleaks dir -v . to scan a folder that is not a git repo.
3. For every real finding, rotate the key in the provider's dashboard first, then move it to an environment variable on your host.

Pay special attention to frontend frameworks. In Next.js, any variable starting with NEXT_PUBLIC_ is bundled into the JavaScript every visitor downloads, so only public values belong there. Payment, email, AI and database admin keys must stay on the server.

Step 2: lock down the database

Many vibe-coded apps use Supabase, because the AI tools wire it up quickly. Supabase's own Row Level Security guide (Supabase docs, 2026) is direct about the risk: a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and it tells you to enable RLS on every table in an exposed schema.

A short checklist for any hosted database:

• Enable row level security on every table the browser can reach.
• Write a policy for each action (read, insert, update, delete) and each role, not one policy that allows everything.
• Test as a logged-out visitor and as a second user: can you read someone else's rows?
• Keep the service or admin key on the server only. The publishable key in the browser is fine only when policies are in place.
• Review the security advisor or equivalent report in your database dashboard before launch.

Step 3: scan the code for risky patterns with Semgrep

Semgrep (LGPL-2.1) is, in its own words, lightweight static analysis for many languages that finds bug variants with patterns that look like source code. It reads your code without running it and flags patterns such as SQL built from user input, unsafe HTML rendering or disabled certificate checks.

Its README walks through semgrep login and semgrep ci to run the default rule sets. Expect some noise on the first run. Fix the findings in login, payments, file uploads and anything that touches personal data first, and mark the rest for review rather than ignoring the whole report.

Step 4: check dependencies with Trivy or OSV-Scanner

AI tools add packages freely, and each one brings its own dependencies. Two scanners check them against public vulnerability databases:

• Trivy (Apache-2.0) finds vulnerabilities, misconfigurations and secrets in containers, code repositories and more. trivy fs --scanners vuln,secret,misconfig . runs all three checks on a project folder.
• OSV-Scanner (Apache-2.0) is Google's scanner that uses data from osv.dev. It can also list licences with osv-scanner --licenses path/to/repository, which helps if a client asks what open-source code ships in your product.

Update packages with a known fix, remove ones the app no longer uses, and be wary of any package name you do not recognise. AI assistants sometimes suggest packages that are misspelled or do not exist, and attackers register look-alike names.

Step 5: test the live site with ZAP

ZAP (Apache-2.0) tests the running site from the outside. Its baseline scan (ZAP docs, 2026) spiders the target for about a minute and reports what passive scanning finds, without attacking the site. Run zap-baseline.py -t https://your-staging-site from the ZAP Docker image against a staging copy.

Typical findings are missing security headers, cookies without the Secure or HttpOnly flags, and pages that reveal server versions. Only scan sites you own or have written permission to test.

UAE-specific checks before launch

The tools above are global. A few points matter more for businesses here:

• Personal data: if the app stores names, phone numbers or Emirates ID details, the UAE personal data protection law (Federal Decree-Law No. 45 of 2021) and free zone rules such as those in DIFC or ADGM may apply. Check current rules with a lawyer or the relevant regulator.
• WhatsApp and form leads: webhooks that push leads to a CRM or a WhatsApp bot need a shared secret or signature check, or anyone can post fake leads into your pipeline.
• Payment links: never build your own card form. Use the hosted checkout of your payment provider so card data never touches your server.
• Arabic input: test forms with Arabic text and long names. Validation written for English input can break or behave oddly with right-to-left text.

Red flags that mean you need a developer

Scanners catch known patterns. Bring in an experienced developer, or a web development team that reviews code for a living, when you see any of these:

• A scanner found a live key that was committed to a public repo.
• You cannot explain who can read each database table.
• The app handles payments, health, finance or children's data.
• Login, password reset or roles were generated by AI and never reviewed.
• Fixing one finding breaks two other features.

A clean scan is a starting point. Rebuilding the risky parts on a maintained stack, such as a reviewed Next.js codebase, is often cheaper than patching an app nobody fully understands.

Make it a habit, not a one-off

Run Gitleaks before every push, and run Trivy or OSV-Scanner weekly or in your CI pipeline. Re-run the ZAP baseline after each major release. Keep a short note of what each tool found and what you changed, so the next person who works on the app, human or AI, does not undo the fix.

Frequently asked questions

Are free open-source scanners enough to make a vibe-coded app secure?

No. They catch common, known problems such as leaked keys, vulnerable packages and missing security headers, but they cannot judge your business logic, such as whether one customer can see another customer's order. Treat a clean scan as a minimum, and have a developer review login, payments and anything that stores personal data.

What should I do if a scanner finds a real API key in my code?

Revoke or rotate the key first in the provider's dashboard, then remove it from the code and move it to an environment variable on your host. Deleting the line alone is not enough, because the old value stays in your git history and in any copy someone already downloaded.