What must be true before you publish?
For an app with private records, a signed-out visitor must not receive them, one ordinary user must not receive another user's records, and a rejected change must leave the stored data unchanged. A hidden button or a redirect to the login screen is not enough evidence.
This is an editorial acceptance worksheet, not a tested repair recipe or a certification. It focuses on data-access boundaries; it is not a complete review of payments, abuse, dependency risk or regulatory obligations. For sensitive or high-impact applications, obtain a qualified security review before relying on a checklist alone.
Define a safe test scope first
Work only on an app and backend you own or have explicit permission to test. Use an isolated test environment, fictional records and two ordinary test accounts. Do not probe someone else's application, use real customer data or run destructive checks against production. Review any external integrations so a test does not send a real email, charge a card or trigger a live automation.
- Identify the target. Record the app URL, backend project, code revision and policy revision. A preview and the published app may use different settings.
- List protected resources. Include private tables, uploaded files, backend functions and administrative actions. Name the owner and intended audience of each resource.
- Separate identities. Use distinct browser profiles for user A and user B, plus a signed-out session. Confirm which account is active before recording a result.
- Prepare controlled records. Give A and B different fictional records and known IDs. You need a known existing record to distinguish a blocked request from a request for something that never existed.
Connector approvals are not app authorization
Official documentation checked October 14, 2026 distinguishes three access paths. A personal chat connection lets Lovable use your external account while you build; it is not included in the published app or available to its visitors. An app MCP integration instead exposes selected actions from your published app to assistants. Browser WebMCP tools are separate again: they work in the person's open tab, using that person's signed-in session.
- For chat connectors, tools the server marks read-only run without asking. Other tools ask unless you change their approval setting. A server's label is not an independent security review.
- Always allow applies to one tool. Allowing all tools from a connection also skips prompts for future tools added by that server. These choices affect your own approvals; review or change them in the connection's Connectors settings. Avoid blanket approval when future actions require review.
- Review published MCP and WebMCP tools separately. Browser tools do not appear in the server's MCP tools list. Lovable says it initially adds read or reversible browser actions, with delete, pay, send, publish or share actions added only when requested; this is not proof that your app's authorization is correct.
- Keep server-side identity, ownership, role and plan checks for each app action. Record exposed tools, returned fields and approvals, then apply the visitor/A/B matrix below to an explicitly authorized disposable test. Tool availability and a successful connection are not blanket action consent.
ShipStackLab has not tested these integrations or inspected your connection settings. Their effective permissions remain UNVERIFIED. Do not enable an integration or grant broader access merely to follow this article.
A visitor / user A / user B permission matrix
The example below assumes private, individually owned records; A and B are ordinary users, not administrators. It also assumes a separate resource intentionally designated as public. Adjust the expected outcomes for team sharing or organization roles before testing. These are proposed expectations, not observed results.
| Action | Visitor | User A | User B |
|---|---|---|---|
| Read A's private record | Denied; no private data returned | Allowed | Denied; no private data returned |
| Edit A's private record | Denied; record unchanged | Allowed within the product's rules | Denied; record unchanged |
| Create a private record | Denied | Allowed with A as owner | Allowed with B as owner, not A |
| Read deliberately public content | Allowed | Allowed | Allowed |
| Use an administrator-only action | Denied | Denied | Denied |
Repeat the private-record cases with B as owner. For each denied read, inspect the response as well as the visible page: private values must not arrive in the browser merely to be hidden by the interface. For an authorized test of a denied edit, verify the stored record remains unchanged. Perform write checks only against disposable test data.
An error or empty response is not sufficient by itself: first confirm the owner can access the known test record. A broken connection could otherwise make every identity look safely blocked. Ask a developer to verify the underlying request paths if you cannot inspect them reliably; do not mark those rows PASS from screenshots alone.
Check the boundary, not just the login screen
Lovable's security guidance distinguishes browser UI from server-side authorization and database row-level security (RLS). Review which identity a backend function uses and what it permits; moving logic off the frontend does not, by itself, define who may invoke it. Do not treat the mere existence of an RLS policy as proof that its conditions express your intended access rules.
Carry the same resource inventory into file access and backend actions. A correct table rule is not evidence about a download URL or an administrative endpoint. If those paths have not been checked, keep them UNVERIFIED instead of borrowing a passing result from the table.
A public key is not automatically a leaked secret
Supabase documents publishable keys for public clients. User identity and data-access policies still matter. Secret keys and legacy service_role keys are elevated credentials, not browser keys. Never expose them in frontend code, public repositories or screenshots. Do not use an administrator credential to test an ordinary user's access: it can bypass the boundary you meant to check.
Storyblok: displaying content is not permission to publish
The Storyblok connector has two permission paths. CDN API is read-only; a public token reads published content, while a preview token can also expose drafts. Management API can create, change and publish content in the spaces authorized at sign-in. Read-only access is therefore not automatically public-content-only.
In Management API setup, all read scopes and most write and publish scopes are selected by default. Write access to spaces, collaborators, releases, webhooks, users and workflows starts off. A connection is initially private, but sharing can extend access to other builders.
- Choose the minimum access. Prefer CDN API with a public token when the app only displays published pages. Keep draft-preview access separate.
- Review before authorization. Record the account, region, spaces, scopes and sharing audience. Remove unneeded write and publish scopes; do not assume the defaults match your task.
- Verify safely. In a disposable space, check that a read-only actor cannot edit or publish and that rejected actions leave content unchanged. Keep production publishing outside the test.
These are proposed acceptance checks, not executed results. ShipStackLab has not connected or tested this integration; your effective permissions remain UNVERIFIED.
Workspace controls: region and API access are different boundaries
EU inference does not relocate stored app data
Checked October 6, 2026: EU inference is available to Enterprise workspace owners and admins. It governs AI model requests during building and requests through the built-in AI connector in published apps, not database or file storage. It uses more credits and restricts models and features; unsupported model requests fail rather than fall back to another region.
This is not an all-tools EU guarantee. Lovable lists web search, web fetch and browser automation as processing their inputs in the US. Provider boundaries also differ: Microsoft's EU Data Zone can include EFTA countries. Changes can take about 20 minutes for new requests; an in-flight request finishes where it started. Review the provider list and your requirements before sending sensitive context.
Restrict the workspace API key, not the app visitor
Workspace API key management requires Business or Enterprise and an owner/admin role. These keys access the Lovable API; they are not Supabase browser keys or your app's user-login policy. Scopes, expiry and an IP allowlist are separate controls.
A request outside a configured allowlist returns 403 ip_restricted. An empty allowlist permits any source address. The list requires an IPv4 entry; Lovable's API connector calls from its connector gateway, not your laptop, so consult its documented gateway ranges before restricting a connector key. IP filtering does not make an over-privileged key safe.
- Record the intended boundary. Name the workspace, owner, required scopes, caller and processing region without copying secret values into the record.
- Check the real caller. Identify the server or gateway making API calls. Do not copy an office IP into a rule meant for hosted automation.
- Retest with permission. In an isolated evaluation, check both allowed and rejected requests and whether required AI features still work. Do not remove a restriction to hide a failed check.
These controls do not replace the visitor/user permission matrix. ShipStackLab has not enabled or tested them in a Lovable workspace; your effective settings and compliance outcome remain UNVERIFIED.
Runtime AI models: inventory before a replacement
Checked October 7, 2026: Lovable's dated announcements say google/gemini-3.6-flash stops working on November 19, 2026, and google/gemini-3.7-flashon January 28, 2027. Existing apps can use them until their respective deadlines; Lovable no longer selects them for new AI features. Lovable recommends google/gemini-3.8-flash as the replacement.
These are models called by your app's AI features, not the models Lovable uses to write your code. A workspace connector's available-model list is not proof of the model configured in a published app. A new model ID is not evidence of equivalent output or a passed security review.
- Record the runtime dependency. Identify the live revision, backend call, provider, exact model ID, responsible owner and cutoff date. Do not copy API keys or private prompts into shared notes. If the app has no affected model calls, mark this checkpoint not applicable.
- Check workspace fit. Review the replacement in Connectors → AI and the workspace's region and retention restrictions. Do not disable a control to make a replacement work.
- Retest before release. With permission, use fictional inputs in an isolated preview to check normal and denied requests, output schemas, error handling, latency and usage cost. Keep the user-access matrix in place and obtain approval before publishing a model change.
This is a source-backed planning checkpoint, not an executed model migration. ShipStackLab has not tested either replacement in a Lovable app; your configured models, compatibility and cost outcome remain UNVERIFIED until recorded.
Dependency checkpoint: identify the deployed framework
Lovable documents TanStack Start for new apps created from May 13, 2026; older apps use React and Vite. Project age is only a starting clue: inspect the actual lockfile and deployed revision. Do not assume all Lovable apps share the same dependencies or patch status.
The September 30 TanStack Start advisorydescribes critical reflected cross-site scripting in server-function responses. In affected apps, opening a crafted link can run attacker JavaScript with the visitor's same-origin access. The affected ranges start at 1.143.12 and exclude the patched versions below.
| Package | Patched version |
|---|---|
@tanstack/react-start | 1.168.60 |
@tanstack/solid-start | 1.168.57 |
@tanstack/vue-start | 1.168.56 |
@tanstack/start-server-core | 1.169.39 |
- Inventory, do not guess. Record the resolved package versions, including start-server-core, from the lockfile used by the live build. A package.json range or a clean scan alone is not that evidence.
- Match the advisory. Ask the maintainer to check applicable packages and arrange a compatible patched dependency set. If versions or deployment evidence are unavailable, keep the result UNVERIFIED and seek the hosting provider's confirmation.
- Validate before release. In an authorized isolated preview, check legitimate server-function actions and the access matrix after the update. Do not run exploit probes on production. Deploy only with approval, then record the live revision; review older public previews separately.
These are editorial review steps, not an executed security test. ShipStackLab has not inspected your project or established whether Lovable has patched your deployment. This dated advisory is not a complete dependency audit. Do not remove permissions or disable controls to make an upgrade pass.
Use scans as evidence, not a guarantee
Lovable's Quick scan checks database access, dependencies and unauthenticated MCP server exposure. Deep scan adds application-code review. The Security view labels these Quick security scan and Deep security scan. The publish dialog starts a Quick scan; Deep scan is not continuously automatic as you work. Publishing an app with sign-in-free MCP access also starts a background Deep scan, and Enterprise administrators can schedule Deep scans. Record which scan actually ran and which revision it covered. A clean scan does not replace the access matrix.
Review every critical finding before public launch. When a fix changes authentication or policy logic, recheck the affected matrix rows and legitimate user actions. A fix that blocks all users may prevent one leak while breaking the product; retain both allowed and denied cases.
Stop conditions and a copyable evidence record
Hold the release if one user receives another user's private data, a denied edit changes a record, an elevated secret is exposed, or a critical scan finding remains unresolved. Unknown coverage is not a pass.
If you encounter real private data, stop, avoid downloading more, preserve only minimal redacted evidence and contact the system owner. A known exposed credential needs owner-led revocation or rotation; removing it from the latest source file alone is not a recovery record. Do not disable RLS or broaden access just to make a failing test pass.
- Target / environment / code and policy revisions: __________
- Resource / fictional test-record ID / intended owner: __________
- Actor / action / expected outcome: __________
- Observed response / stored-state check / redacted evidence: __________
- Result: PASS, FAIL or UNVERIFIED — __________
- Reviewer / date / unresolved finding / retest owner: __________
Save the record in your own project notes; this page does not collect it. Remove tokens, cookies, passwords and personal information from any shared evidence. Revisit the matrix after changes to roles, tables, backend functions or sharing rules.
Where this fits in your launch plan
This checklist addresses access, not whether a builder is fastest or cheapest. Use Lovable vs Bolt for platform boundaries, the cost worksheet for operational budgets, and the migration inventory for ownership and recovery planning. Review the required backup artifacts with the Supabase backup and restore checklist if Supabase is your backend. List the responsible services in Stack Builder; choosing a backend does not establish that its policies have been reviewed.