FAQGet early access

VTProduct

A security inspection for code you didn’t write line by line.

VibeTect is a desktop application that inspects AI-assisted projects for the mistakes most likely to become incidents — and explains each one in language you can act on, whether you’re a founder or a staff engineer.

Get early accessHow it works

01Inspection areas

Five inspection areas, chosen for impact.

Area 01

Exposed secrets

Keys and credentials that end up where anyone can read them.

Why it shows up in AI-generated code

Assistants optimize for code that runs on the first try. Pasting a key inline is the fastest way to make a demo work — and that snippet often lands in a client component, a public environment variable or a committed config file.

What this area covers — examples

  • API keys and tokens hard-coded in source files
  • Secret keys exposed to the browser through client components or public env variables
  • .env files and credentials committed to the repository
  • Admin or service-role keys used where a public key belongs

CWE-798 · CWE-200 · CWE-312

lib/supabase.tsExhibit 01
import { createClient } from "@supabase/supabase-js"; export const supabase = createClient(  process.env.NEXT_PUBLIC_SUPABASE_URL!,  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!);
FlaggedNEXT_PUBLIC_ variables are inlined into the JavaScript sent to every visitor, and a service-role key bypasses Row Level Security entirely.

Area 02

Broken access control

Endpoints that check who you are, but not what you’re allowed to touch.

Why it shows up in AI-generated code

“Add an endpoint to update a user” describes the happy path. Ownership and role checks are unstated requirements, so they are easy for an assistant to leave out — and nothing breaks when they are missing.

What this area covers — examples

  • Records fetched or changed by ID without an ownership check (IDOR)
  • Admin features protected only by hiding a button in the UI
  • Mass assignment — accepting fields like role or isAdmin from the request body
  • Database tables exposed without row-level security policies

CWE-639 · CWE-915 · OWASP A01:2021

routes/users.tsExhibit 02
router.patch("/users/:id", requireAuth, async (req, res) => {  const user = await User.findByIdAndUpdate(    req.params.id,    req.body,    { new: true }  );  res.json(user);});
FlaggedAny signed-in user can update any account, and because the whole request body is applied, they can also send { "role": "admin" }.

Area 03

Unsafe authentication

Login, session and token logic that looks right and isn’t.

Why it shows up in AI-generated code

Authentication is full of details — signature verification, expiry, algorithm choice, hashing cost — that are easy to get almost right. Almost right compiles, passes a manual test and fails against an attacker.

What this area covers — examples

  • Tokens decoded instead of verified
  • Sessions, tokens and reset links that never expire
  • Passwords stored with fast or unsalted hashes
  • Authentication checks that can be skipped by changing a header or parameter

CWE-347 · CWE-287 · OWASP A07:2021

lib/auth.tsExhibit 03
import jwt from "jsonwebtoken"; export function currentUser(req: Request) {  const token = req.headers.get("authorization")?.slice(7);  const claims = jwt.decode(token ?? "") as Claims | null;  return claims?.sub ?? null;}
Flaggedjwt.decode() reads a token without checking its signature, so anyone can forge one for any user ID. Use jwt.verify() with your secret and an explicit algorithm.

Area 04

Risky configuration

Settings that quietly open the door: CORS, debug modes, permissive rules.

Why it shows up in AI-generated code

When something doesn’t work, the quickest suggestion is often to loosen a setting — allow every origin, disable a check, turn on verbose errors. The error goes away. The loosened setting ships.

What this area covers — examples

  • CORS that reflects any origin while allowing credentials
  • Debug mode or detailed error output enabled in production configuration
  • Storage buckets or database rules open to everyone
  • Security checks such as TLS verification disabled to silence an error

CWE-942 · CWE-16 · OWASP A05:2021

server.tsExhibit 04
const app = express(); app.use(cors({ origin: true, credentials: true }));app.use(express.json()); app.listen(process.env.PORT ?? 3000);
Flaggedorigin: true echoes back whichever site is calling. With credentials allowed, any website your users visit can make signed-in requests to your API and read the responses.

Area 05

Vulnerable code patterns

Classic flaws in new code: injection, cross-site scripting, unsafe input handling.

Why it shows up in AI-generated code

Models learned from decades of public code, including decades of insecure examples. Familiar patterns — string-built queries, raw HTML rendering, shell calls with user input — still appear in fresh output.

What this area covers — examples

  • SQL and NoSQL injection from string-built queries
  • Cross-site scripting through raw HTML rendering
  • Command injection through shell calls with user input
  • Path traversal and server-side request forgery from unchecked input

CWE-79 · CWE-89 · OWASP A03:2021

components/Comment.tsxExhibit 05
export function Comment({ body }: { body: string }) {  return (    <div      className="prose"      dangerouslySetInnerHTML={{ __html: marked(body) }}    />  );}
FlaggedUser-written Markdown is converted to HTML and injected unsanitized. A comment containing a script payload runs in every reader’s browser.

Code samples are illustrative examples written for this page. The exact checks, languages and frameworks covered depend on the release you install and will be listed with each release on the download page.

02Findings

Findings that explain themselves.

A list of rule IDs creates work. A clear explanation removes it. Every finding is structured so you can decide what to fix first, understand why it matters and apply the fix with confidence.

High01app/api/invoices/[id]/route.ts:1103

Any signed-in user can read any invoice 02

Why it matters 04

The invoice is looked up by the ID in the URL, without checking who owns it. Anyone with an account can change/invoices/1042 to /invoices/1043 and read another customer’s name, address and billing amounts.

How to fix it 05

Include the signed-in user in the query — for example where: { id, ownerId: user.id }— and return 404 when nothing matches, so the response doesn’t reveal which IDs exist.

Broken access control · CWE-639 · OWASP A01:2021 06

  1. 01

    Severity

    How urgent it is, in one word — so you know what to fix first.

  2. 02

    Plain-English title

    What can go wrong, described as an outcome rather than a rule name.

  3. 03

    Exact location

    File and line, so you can go straight to the code.

  4. 04

    Why it matters

    The realistic consequence: who could exploit it, and what they would get.

  5. 05

    How to fix it

    Specific guidance you can apply yourself or hand to your AI assistant.

  6. 06

    References

    CWE and OWASP mappings for developers who want the full technical context.

03Where it fits

One layer of defense. Know which one.

Different security approaches see different things. VibeTect is designed to be the fast, private check you run before code ships — and to work alongside the others, not to pretend they’re unnecessary.

ApproachVibeTectLocal project analysisExternal scannersLive-app / URL scanningCloud code scannersRepository-connected scanningSecurity professionalsManual penetration test
What it examinesSource and configuration files in the project on your machine.The deployed application from the outside, as an attacker would first see it.Code in your hosted Git repository, often on every pull request.Whatever the testers are scoped to examine, with human judgment.
Access it needsA folder on your computer. No repository permissions.A public URL, and sometimes test credentials.An app or token with access to your repositories.Agreed scope, environments and usually credentials.
Best moment to use itBefore every deploy and after large AI-generated changes.After deployment, to check what is actually exposed.Continuously in team workflows built around pull requests.Before high-stakes launches and for compliance requirements.
What it can missSettings that exist only in hosted dashboards; runtime behavior of the live app.Problems in code paths it can’t reach; issues before they ship.Code that isn’t in the connected repository; requires granting access.Changes made after the test; cost makes it occasional.

For anything that handles payments, health information or other sensitive data at scale, combine approaches — and use VibeTect to clean up the obvious issues before you pay for expert time.

04In your workflow

Run it at the moments that matter.

  1. 01

    Before every deploy

    A local check takes less effort than explaining an incident. Make it the last step before you ship.

  2. 02

    After a big AI session

    When an assistant has rewritten a feature or scaffolded a new one, inspect what changed before you build on it.

  3. 03

    When you add sensitive features

    Authentication, payments, file uploads, admin areas and anything that touches personal data deserve a fresh look.

  4. 04

    Before handover or due diligence

    Deliver client projects — or face an investor’s technical review — knowing the common mistakes are already gone.

See what your AI missed.

Run a local security inspection on the project you’re about to deploy — and fix what it finds while it’s still cheap to fix.

Get early accessRead the vibe coding security checklist

Local analysis · No repository access required