Vallit
Check my appSign in

ProductVera

Security AI that checks its own work.

Our checks flag the places in your code that could let the wrong person in. Vera reads each flag against the exact rule it touches and takes out the false alarms it can rule out.

Check my appRead the study
app/api/orders/[id]/route.tsFlagged by the check: Who can reach which data
1export async function DELETE(req: Request, { params }: Ctx) {2  const session = await auth()3  if (!session) return new Response(null, { status: 401 })4  await db.order.delete({ where: { id: params.id } })First readerFast modelConfirmedIt deletes whatever order the request names. Nothing ties it to the signed-in user.Second readerStronger modelConfirmedAny signed-in user can delete any order by its id.5  return new Response(null, { status: 204 })6}
In your reportHighSigned-in users can reach other customers’ records

Examples, not a customer’s code.

It knows what counts as a problem.

Every check comes with a written rule: what is a problem, and what is not. Vera holds the code up against it.

Who can reach which data
A problem
export async function DELETE(req: Request, { params }: Ctx) {  const session = await auth()  if (!session) return new Response(null, { status: 401 })  await db.order.delete({ where: { id: params.id } })  return new Response(null, { status: 204 })}

Anyone signed in can delete any order.

Not a problem
export async function GET(req: Request, { params }: Ctx) {  const session = await auth()  const order = await db.order.findFirst({    where: { id: params.id, userId: session.user.id },  })  return Response.json(order)}

It only finds orders of the signed-in user.

It answers with one of three verdicts, and we ask it for the line that decides.
  • Confirmed
  • Rejected
  • Cannot tell
Read the rule, word for word
A problem
A signed-in user can read (and receive) or change/delete a record chosen by an id/slug in the request, and nothing ensures the record belongs to them or their team, and no admin/role check applies.
Not a problem
The query filter includes the session user, team, workspace, organisation or project the caller belongs to; the record is loaded and the code stops when it does not belong to the caller; …

What it rules out never reaches you.

What both readers confirm, or can’t settle, lands in your report. The rest you never see.

In your report4

  • DELETE /api/orders/[id]Both readers confirmed itHigh
  • PATCH /api/projects/[id]Neither reader could settle it, so it staysHigh
  • PUT /api/teams/[id]Both readers confirmed itHigh
  • DELETE /api/comments/[id]The readers disagreed, so it staysHigh

Left out4

  • GET /api/orders/[id]The first reader ruled it out
  • GET /api/invoices/[id]The first reader ruled it out
  • GET /api/files/[id]The first reader ruled it out
  • GET /api/meThe first reader ruled it out

These are example flags, not a customer’s.

Found by Vera. Fixed by our team.

Once a problem is confirmed, our team fixes it for your app. Then the same check runs again to prove it’s gone, before anything reaches your code.

OpenCheck the owner before an order is deletedVallit wants to merge 1 commit into main
app/api/orders/[id]/route.ts
  await db.order.delete({ where: { id: params.id } })  await db.order.deleteMany({    where: { id: params.id, userId: session.user.id },  })
  1. Our team wrote the change
  2. The check that found it ran again and no longer finds it
  3. Ready to merge

Tested on code it has never seen.

People who had never seen our checker wrote the test code. We also ran it on real open-source codebases.

  • 0real problems lost
  • 6false alarms caught
  • 87%92%of the flags were real problems
  • 560test cases

The first three numbers come from the two held-out test sets. On real codebases more flags turn out wrong, mostly in old files that are no longer deployed, and the review once set aside a real problem. The study and the coverage page show how we measured. Read the study

It looks where your app points.

Now and then, Vera reads what the daily check saw and picks up to six places worth a closer look, from a fixed list of nine. Our own checker makes those requests. It only reads, and it keeps names and counts, never values.

Read-only requestsNames and counts, never values

What Vera reads

  • A Next.js app
  • The scripts and the /api routes they mention
  • What the last check found

It never sees your address or your company’s name.

Where it looks4 / 9

  1. A source map is publishedGET /_next/static/chunks/main.js.mapThe scripts point to their source maps.A source map at this path names 212 original files.
  2. An API description is publishedGET /api/docsA script fetches /api/docs.The path did not serve an API document.
  3. An API route answers with records to anyoneGET /api/ordersThe scripts call /api/orders before sign-in.The route does not answer without a session.
  4. An environment file is publishedGET /.envThe last check found a public backup folder.No environment file at that path.

An example run. What it finds is filed without your app’s name and reaches you as a finding once a fix exists. Only apps with a confirmed domain take part, and you can leave the sample in your app’s settings.

It also checks the AI inside your app.

If your app runs on AI, three checks look at what could go wrong with it.

NextChecks

See what your app shows to anyone.

Start with a free check. You don’t even need an account to see your score.

Check my appSee plans