Vallit

Release1.13.60

Follow the request

Five new checks follow what a visitor sends all the way into your server. Here is everything Vallit checks, and how well it works.

Everything Vallit checks

Eighteen checks, from the address a visitor types to the data behind your server. Each one sits where it looks.

Checked from outsideRead in your codeNewIn this release

  1. Your address

  2. Your pages

  3. Left in public

  4. Your API

  5. Your server

    Can a request send your server to any address?

  6. Your data

Five new checks follow a request

Each one follows a value from the visitor to the line that uses it and shows you both lines, so you can confirm it before you fix it. They read JavaScript and TypeScript: Next.js, Express and Hono.

Line 2 takes a value from the visitor; line 4 uses it.
export async function GET(request: Request) {  const target = new URL(request.url).searchParams.get('target')  if (!target) return new Response('Missing target', { status: 400 })  const upstream = await fetch(target)  return new Response(await upstream.text())}
From the visitorWhere it lands

A request may send your server to an unintended address

What can happen
A caller may use the server to reach internal services or retrieve information from a destination they control.
How to fix it
Choose destinations on the server where possible. Otherwise validate the parsed URL and resolved IP addresses, block private ranges, and recheck every redirect before connecting.

How well it works

We wrote small programs with known answers, some broken and some safe, and counted what the checks got right. The first run of the new checks fell short of our bar. We fixed what it showed and ran a second set nobody had seen.

Issues found

The five new checks

Our bar 90%

Alert accuracy

The five new checks

Our bar 90%

Issues found

Access control and payments

Alert accuracy

Access control and payments

Website checks

No score yet

  • Up and answering
  • Certificate
  • Search listing
  • Browser protections
  • Cookie protection
  • Insecure content
  • Exposed keys
  • Published config files
  • Backups and open folders
  • Who may call your API
  • Database row security

What these numbers don’t say

  • The examples are small programs we wrote, not your app. Thirty to a set is too few for a promise.
  • The website checks have tests, not a score yet.
  • No other tool has run on these examples, so there is nothing to compare against.

Also in this release

  • What we checked lists the new checksThe report has a fourth group, What a request can make your server do, with one line per new check.
  • Unread code is never a passCode the checks could not read, such as an unsupported framework, is reported as not checked.
  • Progress shows the code checksWhile a scan runs, the code checks appear in the progress list and in the count.
  • Reading a token is not checking itThe access check no longer treats a decoded but unverified token as a signed-in user.
  • Framing protection as browsers see itA frame-ancestors rule set only in the page's HTML no longer counts, because browsers ignore it there.
  • File probes wait for your permissionLooking for files like .env needs you to confirm first that the site is yours.
  • A missing repository shows in the reportIf your repository cannot be read, the website checks still run and each code check says it could not.
Every change since 1.0