Skip to content

Everything a VibeGuard check looks for

A VibeGuard security check tests 14 areas of a live web application with 69 concrete probes: access control and data isolation, authentication, sessions, sensitive data exposure, direct data-layer access, injection and cross-site scripting, server-side request handling, file uploads, business-logic abuse, rate limiting and abuse controls, configuration and browser protections, exposed surfaces, known vulnerabilities in exposed components, and the attack surface introduced by an application's own AI features. Everything is tested from the outside against the deployed application, read-only, without source code or your credentials.

9 min readLast reviewed
01

Who can get in, and what they can reach

Almost every serious finding in an AI-built product lives here. The app looks correct because the interface only ever shows you your own data; the server was never told to enforce it.

Authorization and data isolation

Can one user reach another user's data?

A coding agent writes the query that fetches record 42. Nobody asked it to also check that record 42 belongs to the person asking, and the UI never reveals the gap.

What we try

  • Changing an id in a URL or request body to reach someone else's record
  • Reading, updating and deleting objects that belong to another account
  • Tenant isolation: whether one workspace can see another's rows
  • Function-level checks: admin-only actions called directly, bypassing the hidden button
  • Privilege escalation by editing a role, plan or flag the client sends
  • Mass assignment: fields the server accepts but was never meant to

Authentication

Can someone get into an account that isn't theirs?

Sign-in is generated early and rarely revisited. Password reset, in particular, is the flow that gets least attention and gives away the most.

What we try

  • Brute force and credential stuffing: whether repeated attempts are slowed or stopped
  • Password reset flow: token strength, expiry, reuse, and whether it can be pointed elsewhere
  • Account enumeration: whether error messages reveal which emails are registered
  • Weak or absent password requirements
  • Token and cookie validation: whether a forged or unsigned token is accepted
  • OAuth and magic-link flows: redirect handling and token leakage

Sessions

Once someone is in, how long do they stay in?

Session handling is usually inherited from a template and never checked against how the app is actually deployed.

What we try

  • Cookie flags: HttpOnly, Secure, SameSite
  • Whether signing out actually invalidates the session server-side
  • Session lifetime and idle expiry
  • Session fixation: whether the identifier changes on login
  • Whether an old token still works after a password change
02

What your app gives away

Data does not have to be stolen to be exposed. Most of what we find here is simply being handed out to anyone who asks in the right way.

Sensitive data exposure

Is private information reaching people who shouldn't see it?

Generated endpoints return the whole row because that was the shortest thing to write. The interface shows three fields; the response carries thirty.

What we try

  • Personal data, internal ids and billing details in API responses the page never displays
  • Secrets and API keys shipped inside the browser bundle
  • Source maps, build artefacts and configuration files left reachable
  • Publicly listable storage: uploads, exports, backups, invoices
  • Predictable file URLs that let one customer's document be guessed from another's
  • Data leaking through error messages, search results and export endpoints

Direct data-layer access

Can the database be queried straight from the browser?

Modern AI-built stacks often talk to the database directly from the client. That design is safe only if row-level access rules exist, and generators very often do not write them.

What we try

  • Whether the public API key alone can read tables it should not
  • Whether rows can be inserted, updated or deleted without an authenticated identity
  • Which tables and columns are reachable, including ones the app never uses
  • Whether access rules exist but are written so they always evaluate true
  • Storage buckets exposed alongside the database
03

What happens to what people type

The classic vulnerability classes. Frameworks defend against most of them by default, which is exactly why the places where the default was bypassed are so easy to miss.

Injection and cross-site scripting

Can malicious input change what your app does?

The framework escapes output until someone needs raw HTML, or builds one query by hand, and the agent obliges without comment.

What we try

  • SQL and NoSQL injection in parameters, filters, sorting and search
  • Reflected, stored and DOM-based cross-site scripting
  • Command and template injection where user input reaches the server's own tooling
  • Header and log injection
  • Unsafe rendering of user-supplied HTML or markdown

Server-side request handling

Can your server be tricked into fetching the wrong thing?

Anything that takes a URL — webhooks, importers, link previews, avatar-from-URL — is a request your server makes on a stranger's behalf.

What we try

  • Server-side request forgery, including access to internal addresses and cloud metadata
  • Open redirects used to make phishing links look like yours
  • Path traversal in file and asset serving
  • XML and archive handling where the parser can be pointed elsewhere

File uploads

What can someone put on your server, and what happens next?

Upload endpoints are quick to generate and slow to secure: type checking usually happens in the browser, which is no checking at all.

What we try

  • Whether file type and size are enforced on the server
  • Whether an uploaded file can be served back in a way that executes
  • Whether upload paths can be traversed or overwritten
  • Whether one customer's uploads are readable by another
04

Where the rules of your business can be broken

No scanner finds these. They need someone to understand what your app is for, and then try to get the outcome without paying the price. Pursued in depth on Deep checks.

Business-logic abuse

Can someone get the result without doing the part that costs you?

Every workflow the agent generated assumes the happy path, because that is the path it was described.

What we try

  • Skipping or replaying a step in checkout, onboarding or verification
  • Price, quantity, currency and discount tampering
  • Reusing a one-time code, invite or trial
  • Race conditions on limited resources: seats, stock, credits, referral bonuses
  • Plan and quota enforcement checked only in the interface

Rate limiting and abuse controls

What does it cost you if someone runs your app in a loop?

An endpoint that calls a paid API, sends an email or generates a file is a bill with a public URL in front of it.

What we try

  • Whether expensive endpoints are throttled per account and per address
  • Whether email and SMS sending can be triggered repeatedly at your cost
  • Whether AI features can be called without limit by anonymous callers
  • Whether enumeration of ids, users or invites is slowed at all
05

How your app is set up and served

Cheap to fix and routinely skipped, because deployment happened at the end and the defaults were never revisited.

Configuration and browser protections

Are unsafe defaults still switched on in production?

The settings that made local development pleasant are still in place on the live site.

What we try

  • Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, frame-ancestors
  • CORS policy: whether any origin can call your API with credentials
  • Debug mode, verbose errors and stack traces in production responses
  • Directory listing and reachable configuration files
  • TLS configuration and mixed content
  • Caching directives that let a shared cache store someone's private page

Exposed surfaces

What is reachable that you forgot was there?

Staging environments, old routes and internal tools stay online long after anyone remembers deploying them.

What we try

  • Admin panels and internal dashboards reachable without authentication
  • Development, preview and staging deployments left public
  • Version control, environment and backup files served by the host
  • Documentation, debug and metrics endpoints exposed by a framework
  • Webhook receivers that accept unsigned requests

Known vulnerabilities

Is anything you expose already publicly known to be broken?

Dependencies get pinned once, at generation time, and nothing prompts you to look again.

What we try

  • Component and framework versions your app reveals, matched against published advisories
  • Server and platform software with known issues
  • Publicly documented misconfigurations of the services your stack uses
06

The parts your app added because it is an AI product

If your app has an assistant, a chat box or a generation feature, it has an attack surface that did not exist five years ago and that most checklists still do not mention.

AI feature surfaces

Can your own AI feature be turned against you?

The model will follow instructions it finds in the data it reads. If your feature reads user content, that content can give it orders.

What we try

  • Prompt injection through user-supplied content, files and page text
  • Whether the model's output is rendered as trusted HTML
  • Whether model or provider keys are reachable from the browser
  • Whether AI endpoints are callable without authentication or spend limits
  • Whether one user's conversation or documents can be read by another

What is deliberately out of scope

A coverage list that never says no is marketing. These are the limits of a self-serve check, and they are limits by design rather than gaps we intend to close quietly.

  • Anything behind a privileged account. The check signs up through your own public flow, like any visitor. Surfaces that only an existing admin or an invited team member can reach are not tested. We do not ask you for credentials.
  • Your source code. Nothing is read from your repository. That is a different exercise, available as a custom assessment.
  • Your infrastructure and cloud account. Servers, network exposure and cloud configuration sit outside the application surface. Also a custom assessment.
  • Destructive and denial-of-service testing. Nothing is created, changed or deleted, and we do not test how your app behaves under attack volume.
  • Third-party services your app calls. We only ever test the single address you authorised, never a neighbouring host or a provider you happen to integrate.
  • Mobile and desktop clients. Web only, on the self-serve tiers.

Stop reading. Start checking.

An independent security check of your live app, from €59, with fix prompts for the coding tool you already use.

Check my app

Keep reading