BuiltSafely

Home/Fixes

Base44

Base44: my visitor lookup page stopped working after the security scan's Fix all

A no-login lookup page stopped finding records after Fix all. Use Base44's Fix the visitor lookup page button, and don't make the table public again.

  • Docs-only
  • Reviewed Oct 2026
  • 3 official sources
Sources Last checked October 20, 2026 · Badge: docs-only (official Base44 docs and changelog; we didn't reproduce this on a Base44 app) · Sources: official docs (linked below) · Educational, not an audit

Based on Base44's docs, not tested in a live app. Everything on this page comes from Base44's official documentation and changelog (last checked Oct 20, 2026). We haven't reproduced the break or the repair in a live Base44 app, and we flag the places where the docs leave gaps.

The fix

Use the repair button Base44 added for this case. Don't make the table public again.

  1. Open your app's AI chat and find the message for the security fix you applied. Base44 records every scan fix as a chat message (Base44: Running a security scan).
  2. Click Fix the visitor lookup page. Base44's scan docs say the button appears in that fix's chat message; the changelog (October 17, 2026) describes it on the fix's result card. Either way, it's offered when Fix all breaks a lookup page that visitors use without logging in, and it "sends the AI chat a prepared request to repair the page" (Base44 changelog). The scan docs say the request aims to get the page working again "while keeping the records private" (Base44: Running a security scan).
  3. Review what the AI proposes before you approve it. Base44 adds a chat card for every data permission change, so you can see exactly what changed (Base44 changelog).
  4. Test the page (see How to verify below), then run the security scan again.

Why it happens

Some apps that don't require login have a page where a visitor looks up something they submitted earlier, such as a booking, without signing in. Base44's docs say a data permissions fix "can break" that kind of page (Base44: Running a security scan).

That's the tradeoff. Before the fix, the page could read the records because the table was open to visitors who aren't signed in. Fix all tightens the table's permissions so strangers can't read everyone's records. The lookup page was relying on that same open access, so it stops working too.

What you're likely to see. Base44's docs don't list a specific error message for this case. Going by how Base44 documents denied reads, expect the page to behave as if the record doesn't exist rather than show a permission error. A denied list or filter "Returns an empty result, the same as if nothing matched," and a denied single-record fetch returns a not-found error (HTTP 404) (Base44: Entity security). Base44 also notes that a rule which checks the signed-in user blocks a visitor who isn't signed in "outright" (Base44: Entity security). So "no booking found" for a booking you know exists, right after you applied Fix all, points to this cause.

What not to do

  • Don't set the table's Read permission back to everyone ("All Users") to get the page working. That puts every visitor's records back in reach of anyone, which is what the scan flagged in the first place.
  • Be careful with reverting. Base44 lets you roll a fix back from its checkpoint in the chat (Base44: Running a security scan). That brings the page back, but it also brings the exposure back. Use it only as a short stopgap while you apply the repair, if at all.
  • Don't "Acknowledge" the data permission issue just to silence it unless you've confirmed that data is meant to be public.

AI prompt

Use the Fix the visitor lookup page button first, since it sends Base44's own prepared request. If you're working in the chat yourself, a prompt like this keeps the same goal:

After the security scan's Fix all, my no-login lookup page (where visitors look up
something they submitted, like a booking) no longer finds records.
Get that page working again while keeping the records private: a visitor must only
be able to see the one record they submitted, never list or browse other records.
Do not set read permission to All Users on this table.
Explain the change and wait for my OK before applying it.

How to verify

  1. In a private browser window (not signed in), submit a new test entry, then look it up on the lookup page. It should be found.
  2. Still signed out, try to see other people's entries: look up a value you didn't submit, or change an ID in the page address. You should get nothing back.
  3. Run the security scan again and confirm no new data permission issue appears for that table. If you changed the app after the last scan, Base44 asks you to rescan before applying more fixes (Base44: Running a security scan).

Only test apps you own.

Base44 security guide · How to judge a free security scanner · Never let users edit the field your access rule trusts

Your turn

Did Fix all break a different kind of page in your app, such as a form or a shared link? Tell us which, and we'll add it here.

This guide is educational and based on the vendor's public docs as of the review date. Platforms change: check the linked sources. Not a security audit. Disclaimer.

The BuiltSafely weekly

One email a week. What changed, and the one fix that matters.

Platform changes that affect the security of AI-built apps, checked against official docs. Free. Unsubscribe any time.