SCAN YOUR DATABUTTON APP FOR VULNERABILITIES

Databutton’s agent builds full-stack apps — a React frontend and a real Python FastAPI backend — and deploys them on the platform’s managed hosting. That means every app ships an actual API surface: routers, endpoints, Pydantic models, and CORS middleware, all generated to work on the first try. “Works” and “hardened” are not the same thing, and the gap is exactly where a black-box scan pays off.

The platform itself is sound. It gives you a secrets store, managed deploys, HTTPS, and scheduled jobs that run server-side. The vulnerabilities live one layer up, in the application code the agent writes: FastAPI routes that ship without an auth dependency, CORSMiddleware configured to allow all origins with credentials, /docs and /openapi.json left enabled in production, and third-party API calls that end up in the React bundle instead of behind the secrets store.

A scanner exercises the deployed URL the way an attacker would — enumerating endpoints, calling them logged out, replaying one user’s requests as another. That is the fastest way to find the routes the agent generated without the checks you never explicitly asked for.

Common vulnerabilities we find in Databutton apps

Unauthenticated FastAPI endpoints

The agent generates working CRUD fast, and working does not include authentication unless the prompt asked for it. A generated /routes/projects/{id} returns data without checking who is calling, so anyone with the deployed URL can enumerate it with curl. The exploit is trivial: hit the endpoint from a logged-out session and read what comes back. The fix is a shared get_current_user dependency attached at the router level (APIRouter(dependencies=[Depends(get_current_user)])) so a forgotten route fails closed instead of open.

Broken object level authorization

Even when auth is wired, generated lookups trust the client-supplied ID and return whatever they find. Sign in as user B, replay a request that carries user A’s project_id, and you get user A’s record. This is BOLA in AI-generated CRUD, the most common finding in AI-built backends. The fix is an ownership check after every ID-keyed lookup — compare record.owner_id to the authenticated user’s UID and return 403 on mismatch.

Open CORS with credentials

Generated middleware frequently ships allow_origins=["*"] together with allow_credentials=True, because that removes all development friction. That combination lets any website make credentialed requests to your API from a logged-in visitor’s browser and read the response. The fix is a one-line change: allowlist your production origin only. See CORS + credentials misconfig.

API keys in the browser bundle

The secrets store is the correct home for third-party keys, but it only protects calls that stay server-side. When the agent wires a Stripe, OpenAI, or Resend call directly into a React component, the secret key ships in the deployed JavaScript where anyone can extract it. The fix is to route every secret-key call through a FastAPI endpoint that reads the key from the secrets store, then rotate anything that ever shipped client-side. The Token Leak Checker finds keys in the bundle for you.

Mass assignment via loose models

Pydantic models exist in the generated code, but write endpoints sometimes reuse the storage model or accept extra fields. If a request body can carry owner_id, role, or is_admin, a user can set attributes that own your authorization model. The fix is a strict input model — model_config = ConfigDict(extra="forbid") — that rejects unexpected fields, with owner and role set server-side, never from the body. See mass assignment.

Information disclosure

FastAPI serves /docs, /redoc, and /openapi.json by default — a complete, typed map of every route and parameter for anyone who visits. Paired with verbose validation errors and raw exception strings, an attacker learns your whole surface without guessing. The fix is to construct the app with FastAPI(docs_url=None, redoc_url=None, openapi_url=None) and return generic errors from a global exception handler while logging details server-side.

How VibeEval works with Databutton

1. Enter your deployed Databutton app URL. No repo access, no config — the scan runs against the live app the way a visitor reaches it.
2. The agent probes the app in the browser. It enumerates the FastAPI endpoints from the frontend’s network traffic, calls each one logged out to find missing auth, replays requests across two accounts to find BOLA, inspects the CORS response headers, checks whether /docs and /openapi.json answer, and greps the deployed bundle for leaked key prefixes.
3. You get a report you can act on. Each finding carries a severity, the request that demonstrates it, and a paste-ready fix prompt you can feed straight back into the Databutton agent for one-shot remediation.

Manual testing vs VibeEval

Manual review still wins on logic no scanner understands — whether a workflow should let a user do a thing at all. The scanner wins on repeatability: it re-runs the mechanical auth, BOLA, CORS, and leak checks after every agent edit, when hand-testing has long since stopped.

Frequently asked questions

Does VibeEval have special support for Databutton?

Yes. VibeEval recognizes the React + FastAPI stack Databutton generates and tests for the platform’s recurring failure modes: routes missing auth dependencies, exposed OpenAPI schemas, open CORS with credentials, and keys that drifted into the bundle.

When should I scan a Databutton app?

Deploy the app and scan the deployed URL before you share it with real users. The generated code is only exercised as an attacker would exercise it once it is live, so the deployed pass is the meaningful one.

What authentication issues are most common in Databutton apps?

Missing auth dependencies on FastAPI routes, missing ownership checks on ID-keyed lookups, and tokens that are decoded but not verified server-side (signature and audience). All three are mechanical to fix once you know which routes have them.

Are keys in the Databutton secrets store safe?

Yes, while they stay server-side. The store protects any key a FastAPI endpoint reads. The risk is generated code that calls a third-party API from React, which ships the key in the browser bundle regardless of the store. Route those calls through the backend and rotate anything that ever shipped client-side.

Related Databutton resources

• How to Secure Databutton — the step-by-step hardening guide behind these checks.
• Is Databutton Safe? — in-depth analysis of the platform’s defaults and what to audit before launch.
• Databutton Security Checklist — the pre-launch checklist version.
• Token Leak Checker — find exposed API keys in your deployed bundle.
• BOLA in AI-generated CRUD — the ownership-check pattern in depth.

Test your Databutton app before launch

Run VibeEval against your deployed Databutton URL for the missing-auth, BOLA, open-CORS, exposed-docs, and credential-leak patterns the agent most often leaves in. Start testing before you go live.