Before you launch, ask for a security audit

Launch morning: every customer’s orders, open to anyone

In our reel, a founder launches an app built with AI. That morning they log in as a test customer and see everyone’s orders: names, addresses, phone numbers. The orders page never checked who was asking. And who wrote the orders page? The AI owns up: “You said ‘just make it work.’ It works. For everyone.”

Why the AI didn’t check

AI coding tools write what you ask for. Ask for “a page that shows the orders” and you get a page that shows the orders. All of them. Deciding who is allowed to see what is a separate job, and unless you ask for it, it often doesn’t get done. As the AI puts it in the reel: “You never asked me to run a security check.”

This mistake has a name: broken access control. OWASP, a nonprofit that tracks the biggest security risks for web apps, ranks it number 1 in its 2025 Top 10, and says 100% of the apps it tested had some form of it (OWASP Top 10:2025).

A simplified example in the style of the reel. Your app’s code will look different. Finding the real lines is the auditor’s job.

The fix: a free security auditor from Cloudflare

Cloudflare, the internet security company, released security-audit-skill for free on June 18, 2026, together with a blog post about it. A skill is a set of written instructions that your coding agent (an AI that writes and runs code on your computer, like Claude Code) reads and follows. Cloudflare’s README says it “turns your agent into a security auditor”.

Made by

Cloudflare

Licence

MIT Free to use, change and share

Price

Free Running it uses your AI plan

GitHub stars

About 54,700 Checked October 31, 2026

It’s also where Cloudflare’s own bug hunting began. The README calls it “the skill that seeded Cloudflare’s vulnerability discovery harness”: the bigger system Cloudflare later built to hunt for security holes in its own code. That bigger system isn’t public. This skill, its starting point, is.

How it works, in plain words

1. It maps your app

   Helper agents read your code and map it: the pages, the API routes (the addresses your app uses behind the scenes to fetch and change data), the database, and where the trust lines are, like logged in versus logged out.

2. Hunters try to break it

   Separate “hunter” agents each take one part of that map and try to break it, rather than just read it.

3. A fresh agent tries to prove each finding wrong

   Every possible hole goes to a new agent whose job is to disprove it. In the README’s words: “The agent that checks a finding is never the agent that found it.”

4. You get a report

   What survives is sorted into confirmed, needs validation and rejected, re-checked by fresh agents, and written up with the smallest fix for each. It tells you the fix; its instructions say it doesn’t edit your code.

Step 1: Install it with one line

What you need first:

• A coding agent that can run several helper agents at once. The README doesn’t name specific agents. It asks for “a model that supports tool use and parallel sub-agents”. Claude Code is one that does.
• Node.js, a free program the installer runs on: version 22.20 or later, according to the installer’s README. Download it from nodejs.org.
• Your app’s code in a folder on your computer.

Open a terminal (the window where you type commands) in your project’s folder, the same folder you open in your coding agent. Then run this line:

The installer asks which coding agents to add the skill to. It works with Claude Code, Codex, Cursor, OpenCode and 75 more (Skills CLI README, checked October 31, 2026). Pick the one you use. The skill goes into this project only; add --global to the end of the line to have it in every project.

If your coding agent was already open, start a new session so it loads the skill.

The installer is Vercel’s open-source Skills CLI. Its makers say it collects anonymous usage data, which you can turn off by setting DO_NOT_TRACK=1.

Step 2: Paste this prompt

Start your coding agent in your project’s folder and paste this in. The first line is the request Cloudflare’s README gives, which starts the full audit. The rest tells it to look at who can see what first, to answer in plain English, and to wait for you before changing anything.

Security audit this codebase. Use the security-audit skill and run the full audit. Save the report in the skill's default output folder, outside this project.

I'm not a developer, so explain everything in plain English.

Start with "who can see what". Check every page and every API route (the addresses the app uses to read or change data):
- Does it check who is logged in?
- Does it return or change only that person's own data, never another customer's?
- Can someone get another customer's data by changing a number or ID in the address?
Look hardest at orders, payments, profiles, messages, uploads and admin pages. Then audit the rest of the app as usual, including where passwords, API keys and other secrets are kept.

When you're done, give me a short summary:
1. Confirmed findings, worst first. For each one: how serious it is, the file (and line), what a stranger or another customer could do, and the fix in one or two plain sentences.
2. "Needs validation" leads, each with a simple way I can check it myself using two test accounts, never real customers' data.
3. Anything you couldn't check.

Don't change any code yet. I'll tell you which fix to make first.

While it runs

• It may ask you one question first, such as how deep to go. Answer it, then let it work.
• It starts many helper agents, so it can take a while and use a good share of your AI plan. On a smaller plan, add this line to the prompt for a shorter first pass. The skill calls it a “fast first look”:
  Use the quick profile.
• The report is saved outside your project, by default in a folder named security-audit-skill in your home folder. Start with REPORT.md.

Step 3: Fix the worst first, then run it again

1. Fix one thing at a time, worst first

   Start with anything marked critical or high. Ask for one fix at a time, so you can see what changed:

   Fix finding 1 only. Show me what you changed, and tell me how to check it worked with two test accounts.

2. Check it yourself

   Do the two-account test from the checklist below. In the reel, after the fix, the test customer sees one order, their own, instead of everyone’s.

3. Run the audit again

   Paste the Step 2 prompt again after your fixes. The README says runs on the same code add up: each new run reads the earlier results and goes after the gaps.

Honest catches, from Cloudflare’s own docs

• One run finds about half

  In Cloudflare’s test runs, “a single run found roughly half” of the problems that repeated runs found in total (README). Their blog says the same: “a single run finds only about half the bugs” (Cloudflare blog, June 18, 2026). So run it more than once, and again before each launch.

• Proving a hole needs a sandbox

  To prove a problem by actually running your code, the skill needs a locked-down test space called a sandbox: no internet, only safe test settings, strict limits, and nowhere to save files except a scratch folder. Without one, it “keeps the lead as needs_validation instead of executing target code” (README). Most laptops aren’t set up that way, so expect some findings marked needs validation. That means not proven either way. Check them with the two-account test, or ask a developer.

• A clean report isn’t a guarantee

  Writing about the bigger system that grew out of this skill, Cloudflare says: “We don’t claim a false-negative rate for our system” (Cloudflare blog). In plain words: no one can promise it found everything.

• It reads your code, not your live site

  The skill is told not to test your live website or touch real users’ data (SKILL.md). Settings that live outside your code, like your hosting or your database dashboard, are out of its sight, so it marks them “needs validation” instead of guessing. That’s what the checklist below is for.

Before every launch: 7 checks anyone can do

Use two test accounts you made yourself, never real customers’ accounts. Tick each check off as you go. The ticks aren’t saved anywhere.

1. Two accounts: can B see A’s stuff?

   Make test accounts A and B. As A, place an order (or save anything private) and copy that page’s address. Log in as B in a private browser window and paste it. You should get an error or “not found”, never A’s data.

2. Change the number in the address

   If an address has a number or ID in it, like /orders/1041, try the numbers next to it while logged in as B. Every one should be refused.

3. Log out and try again

   In a private window, logged out, paste the same addresses. You should land on the login page or see an error.

4. Try the admin pages as a customer

   Logged in as a normal test account, open your admin or dashboard pages (for example /admin). You should be turned away.

5. Ask where your secrets are kept

   Secret keys (for payments, email or the database) belong in your host’s secret settings, often called environment variables. Never in your code, and never in anything the browser downloads. Ask your coding agent:

   Where are my API keys, passwords and other secrets stored? Is any of them in my code, my Git history, or anything sent to the browser?
6. Check the database itself

   Some databases, like Firebase and Supabase, can be reached straight from the browser, so their access rules matter as much as your pages. Ask:

   Can anyone read or change my database directly, without going through my app's login? Check my database rules or row-level security.
7. Run the audit once more

   After your last change, paste the Step 2 prompt again. One run finds only part of what repeated runs find.

Found something? Fix it before you launch, then do the check again. The reel ends with the founder saying “Run it before every launch.” and the AI answering “Only if you ask!” That’s the whole lesson: ask.

Credits and sources

security-audit-skill by Cloudflare (github.com/cloudflare/security-audit-skill), MIT licence. The short quotes on this page come from its README, its SKILL.md file and Cloudflare’s blog post; everything else is in our own words. The installer is the Skills CLI by Vercel (github.com/vercel-labs/skills), MIT licence.

Sources, all opened and checked on October 31, 2026:

1. [1] Cloudflare, security-audit-skill README on GitHub: install line, how to run it, requirements, “roughly half”, MIT licence. About 54,700 stars on October 31, 2026.
2. [2] Cloudflare, SKILL.md: the quick profile, the default report folder, no edits to your code, no testing of live sites.
3. [3] Dan Jones, Alexandra Godoi and Grant Bourzikas, “Build your own vulnerability harness”, Cloudflare blog, June 18, 2026 (updated July 15, 2026).
4. [4] Vercel, Skills CLI README: supported agents, Node.js 22.20 or later, anonymous usage data.
5. [5] OWASP, “A01:2025 Broken Access Control”, OWASP Top 10:2025.

MIT License

Copyright (c) 2025-2026 Cloudflare, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.