SCAN YOUR RORK APP FOR VULNERABILITIES

Rork is a prompt-to-app-store pipeline: you describe an app in natural language, it generates a cross-platform React Native + Expo build, wires it to a hosted backend — typically Supabase or Firebase — and points you at store submission. The mobile binary itself has no URL to scan, which is why the scanner asks for your app’s backend URL: the Supabase project, Firebase config, or generated API layer the app calls. That backend is also the only part of the system you still control after release.

The mobile context changes what “vulnerable” means. Everything Rork compiles into the APK/IPA — anon keys, endpoint URLs, feature flags, premium logic — is extractable by anyone with the store build and free tooling, so client-side checks are decoration and the backend rules are the entire auth boundary. And unlike a web deploy, a shipped mistake cannot be rolled back: a secret in a released binary stays leaked until every user updates, with store review sitting between you and the fix. The audit has to happen before submission, not after.

Common vulnerabilities we find in Rork apps

Six failure modes recur in Rork-generated apps. All of them are reachable from the backend URL, because that is exactly how an attacker reaches them — the app is optional.

Open backend rules behind the shipped anon key

The Supabase anon key or Firebase config in a Rork bundle is designed to ship — but only when Row Level Security or Firestore rules scope every table and collection. The recurring finding is rules missing on a newly prompted table, or set to “any authenticated user” instead of the owner, which turns the extractable key into a data-dump credential. Exploit shape: pull the key from the APK, query the REST endpoint directly, read every user’s rows. Fix direction: RLS on every table with policies keyed to auth.uid(); Firestore rules gated on request.auth.uid == resource.data.owner_id. Deny by default.

Server secrets compiled into the bundle

When a prompted feature needs OpenAI, Stripe, or a service-role client, the generator often makes the call from the app — key included. Every such string is recoverable from the shipped binary, and mobile adds the trap the web doesn’t have: there is no instant rotation for a released build. Rotating breaks installs that still carry the old key, and archived copies keep it forever. Fix direction: every secret-requiring call moves behind a server-side function before the first release; rotate anything that ever shipped and treat the shipped copy as burned.

BOLA on the generated API layer

Rork-generated Edge Functions, Cloud Functions, and CRUD routes routinely check the session but not ownership — or check nothing at all. Exploit shape: sign in as user B, replay user A’s record ID against the endpoint extracted from the bundle, receive A’s data with a 200. This is BOLA in AI-generated CRUD in its purest form. Fix direction: every ID-keyed route validates the session, then confirms owner_id === user.id before returning anything.

Client-side entitlement checks instead of receipt verification

Premium gating generated as a React Native conditional — if (user.isPremium) — is flippable in a patched binary and skippable by calling the premium endpoint directly. The store receipt is the only trustworthy purchase evidence, and only the server should evaluate it. Fix direction: the client sends the receipt to your backend, the backend verifies it against Apple/Google, writes the entitlement to the database, and backend rules gate premium data on that flag. The client renders is_premium; it never decides it.

Session tokens in AsyncStorage

Generated auth flows persist session and refresh tokens in AsyncStorage — unencrypted on both platforms, readable on compromised devices and via some backup paths. Fix direction: move anything credential-shaped to expo-secure-store (Keychain on iOS, Keystore on Android), and if Supabase auth is in play, pass a SecureStore-backed adapter as the client’s storage option:

import * as SecureStore from "expo-secure-store";
await SecureStore.setItemAsync("session_token", token);

Unvalidated deep links

Generated deep link handlers accept whatever arrives: myapp://reset-password?token=...&redirect=... with no validation, and custom schemes can be claimed by other apps on the same device. Exploit shape: a crafted link sent to your users that redirects an auth flow or injects state into the app. Fix direction: validate every parameter, allowlist redirect targets, never derive auth state from a link alone, and prefer verified universal links / app links for anything security-relevant. See SSRF, open redirects, and OAuth for the redirect side of this pattern.

How VibeEval works with Rork

1. Enter the backend URL your Rork app calls — the Supabase project URL, Firebase endpoint, or generated API base. That is what attackers hit with the config extracted from your APK/IPA, so it is what the scanner hits too.
2. The agent probes it the way an attacker would. Browser-driven and direct-API testing: querying tables with only the anon key and no session, replaying one account’s resource IDs from another account (BOLA), attempting writes to privileged fields like role and is_premium, calling premium endpoints with a free-tier token, and checking auth flows, headers, and error responses for leakage.
3. You get findings with severity and paste-ready fix prompts. Each finding names the endpoint or table, shows the request that proved it, and ships a remediation prompt you can paste straight into the Rork chat — plus the SQL or rules change where the fix belongs in the backend console instead.

Manual testing vs VibeEval

Manual review still matters — no scanner understands your business logic. Where the scanner wins is repeatability: Rork regenerates auth flows, storage calls, and API wiring every time you prompt a change, and a check you ran last week says nothing about today’s build.

	Manual testing	VibeEval
Time per pass	Hours: two test accounts, per-table rule review, per-endpoint replay	Minutes against the backend URL
Cross-user (BOLA) coverage	The endpoints you remember to try with account B	Every discovered endpoint, systematically
After each Rork regeneration	Full re-test, usually skipped	Re-run the same scan, diff the findings
Backend rules vs shipped key	Console review per table, easy to miss one	Probed from outside with only the client config
Business logic and UX flows	Where humans are essential	Out of scope
Cost	Your pre-submission time, every release	Flat, per scan

Frequently asked questions

Does VibeEval have special support for Rork?

Yes. VibeEval recognizes the Rork stack — React Native + Expo clients against Supabase or Firebase backends — and runs the mobile-specific probe set: open rules behind a shipped anon key, missing route auth and ownership checks, privileged-field writes, and entitlement endpoints that never verify a receipt.

Why does the scanner ask for a backend URL instead of my app?

Because the mobile binary has no URL — and because the backend is where the attack happens. Anyone with your store build extracts the API endpoint and client config in minutes and queries the backend directly, skipping every check in the React Native code. Scanning the backend tests the boundary that actually holds.

Can I scan during Rork development, before store submission?

Yes — scan as soon as the backend exists, and definitely before the first release. On mobile this ordering matters more than on web: bundle-side mistakes like an embedded secret cannot be rotated out of a shipped binary, so they must be caught before the build reaches the stores, not patched after.

What authentication issues are common in Rork apps?

Missing auth on generated API routes, backend rules scoped to “any authenticated user” instead of the owner, session tokens in AsyncStorage instead of SecureStore, entitlements decided client-side without receipt verification, and deep link handlers that trust their parameters.

How does Rork security compare to web builders like Lovable or Bolt?

The generated-code habits are the same — rules lag the schema, CRUD skips ownership, gates land in the client. Mobile amplifies the cost: the client ships to the attacker in full, and a leaked secret persists on users’ devices until they update instead of being one redeploy away from fixed. Same bugs, higher stakes, no quiet fix after launch.

Related Rork resources

• How to Secure Rork — the 15-step hardening guide, from bundle hygiene to regeneration re-audits.
• Is Rork Safe? — in-depth analysis of the Rork generation pattern and the six areas to harden.
• Rork Security Checklist — pre-launch checklist ordered by severity, launch-blocking items first.
• Supabase RLS Checker — verify the anon key in your bundle is safe to ship.
• Firebase Scanner — probe Firestore rules from outside, the way an attacker would.

Test your Rork app before launch

The backend behind your Rork app is public the moment the binary is — every key and endpoint in the bundle is extractable, and only the backend rules stand between the shipped key and your data. Scan the backend URL before store submission, fix with the paste-ready prompts, and re-scan after every regeneration.