What is a vibe coding security check?

Q: What is a vibe coding security check?

A vibe coding security check is an independent security assessment of a web application that was built partially or primarily with AI coding tools. It tests the deployed application from the outside — the way an attacker meets it — rather than reviewing source code, and it returns prioritised findings with the evidence behind each one and instructions to fix them. It exists because AI coding tools produce applications that work correctly while quietly omitting the checks that stop a stranger from reading someone else's data.

The short definition

Three properties make it a security check rather than something else. It is independent: it does not start from your intentions, your architecture diagram or the question you thought to ask. It is black-box: it works against the running application at a public address, with no source code and no credentials handed over. And it is evidence-based: every finding names the request that produced it and the response that came back, so you can reproduce it yourself before you spend an afternoon fixing it.

“Vibe coding” is the part that describes the audience, not the method. The test is the same one you would run against any web application. What changes is which failures are likely: an application assembled quickly by a model, by someone who is a founder first and a security engineer never, fails in a distinctive and very predictable set of places.

What it is not

Being precise about this saves everyone time.

It is not a code review. Nobody reads your repository. That is a different and complementary exercise, and it is the one your coding agent is already good at.
It is not a dependency scan. Snyk, Dependabot and npm audit read your lockfile and tell you which libraries have published advisories. Keep them switched on. They cannot tell you whether your own authorization logic works.
It is not a penetration test. A pen test is a human specialist working for days under contract, with manual exploitation and a formal report, and it typically starts in the thousands. If an auditor or an enterprise contract names a penetration test, a check does not satisfy that requirement. We wrote the full comparison, including the cases where we are the wrong answer.
It is not a compliance certificate. It produces evidence you can show, not an attestation somebody else signed.

What it covers

14 areas, 69 concrete things tried against the live application. Grouped, they are:

Who can get in, and what they can reach. Authorization and data isolation, Authentication, Sessions.
What your app gives away. Sensitive data exposure, Direct data-layer access.
What happens to what people type. Injection and cross-site scripting, Server-side request handling, File uploads.
Where the rules of your business can be broken. Business-logic abuse, Rate limiting and abuse controls.
How your app is set up and served. Configuration and browser protections, Exposed surfaces, Known vulnerabilities.
The parts your app added because it is an AI product. AI feature surfaces.

The full coverage page lists what is actually attempted in each area, down to the individual probe.

Why your coding agent can't do this for you

This is the objection worth taking seriously, because asking Cursor or Claude Code to “check my app for security issues” is free and takes thirty seconds. You should do it. It will find real things. It will also miss the category of problem that actually leaks customer data, and it will miss it structurally rather than by bad luck.

A coding agent reasons about the code it can see, in response to the instruction it was given. Four consequences follow:

It does not observe behaviour. Whether GET /api/users/1042 returns another customer's record is a fact about the deployed system: the database rows, the session in the browser, the middleware that did or did not run. You cannot read it off the source.
It cannot see outside the repository. Your hosting platform's headers, your database's access policies, your storage bucket's permissions and the preview deployment still serving last month's admin panel are all part of your attack surface and none of them are in a file.
It answers the question you asked. You cannot ask about a risk you do not know exists, and the ones that matter are precisely the ones nobody thought of.
It marks its own homework. The model that wrote the authorization logic is being asked whether the authorization logic is correct. Independence is not a formality here.

The two are complementary, and the order matters: an outside test finds the problem, and your agent, handed a precise description of it, fixes the problem very well.

When to run one

Before you open sign-ups to the public, or take a first paying customer. Both change who is looking at you.
After you add authentication, payments, file uploads, an admin area, or anything that stores personal data.
After a large refactor generated by an AI tool, especially one that touched routing, data access or middleware.
When you connect a database that the browser can reach directly. This is the single highest-risk moment in a modern AI-built stack.
When a customer, investor or partner asks what you have done about security, and you would rather answer with a document than a promise.

What you get back

A report, ordered so the finding that can actually hurt you is first. For each one:

What was found, in plain English, and the endpoint it affects.
Why it matters, and what a realistic abuse of it looks like.
The evidence: the request that was sent and the response that came back, so you can reproduce it.
A severity rating, with the CWE and CVSS score for the technically minded.
A fix prompt written for an AI coding tool, stating the expected behaviour and a test that proves you reached it.

You can read a full example report before buying anything. It uses sample data from a fictional application; the structure is exactly what a real one looks like.

And if nothing serious turns up, you still get the report. It lists what was tested and what held. That document is a far better answer to a procurement questionnaire than an assurance, and we do not pad findings to justify an invoice.

What to do after a vulnerability is found

Read the plain-English explanation and decide how urgent it is. Critical and high findings come first; a missing security header can wait until Thursday.
Reproduce it yourself using the evidence. It takes two minutes and it means you understand the problem rather than trusting a label.
Paste the fix prompt into your coding tool, and review the change it proposes the way you would review any change. Do not merge a security fix you have not read.
Deploy, then run the included fix verification re-check. It re-tests the original findings and tells you which are resolved, which are still present, and which were inconclusive.
Keep the report and the re-check. Together they are the evidence that you found something, fixed it, and confirmed the fix.

What it costs

A one-time payment, from €59 for a Quick check to €199 for a Deep one, with no subscription and no card kept on file. The difference between the tiers is how far the assessment gets, not which features are switched on: every tier includes the same report, the same evidence, the same fix prompts and one re-check. The pricing page compares them row by row.

If you need infrastructure, cloud configuration or an actual source code review as well, that is a custom assessment: our own team, scoped and quoted with you before anything starts.

Gartner has forecast that 40% of new enterprise production software will be built with vibe coding techniques by 2028. The gap between how fast software is now built and how carefully it is checked is the reason this service exists.